springframework-developer — Spring Framework developers list

Re: [Springframework-developer] IoC container enhancements

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

James,

I'll take another look at the Wiki page.

Rgds
Rod

----- Original Message -----
From: "James Cook" <jim...@do...>
To: <spr...@li...>
Sent: Friday, June 25, 2004 2:40 PM
Subject: RE: [Springframework-developer] IoC container enhancements


> Since you are enhancing the injection support for the container, do you
> think it is worthwhile adding syntax to support Type 1 (Interface
Injection)
> IoC?
>
>
http://opensource.atlassian.com/confluence/spring/display/DISC/Adding+Interf
> ace+Injection+to+Spring

Re: [Springframework-developer] Retrieve all class path resources with the same name

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

I quite like "classpath*:" too: It's a resource pattern prefix, just =
like "classpath:" is a resource location prefix. Everything after the =
":" should be the actual resource pattern, so I don't really like a "*" =
there.
=20
"classpath*:*-beans.xml" will _not_ work, as the implementation =
considers the path after "classpath*:" a standard classpath resource =
location. This means that the location after "classpath*:" is not =
supposed to contain an Ant-style pattern in any case; it will not be =
parsed but rather passed straight through to the ClassLoader.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Tom Turelinckx
Gesendet: Fr 25.06.2004 12:16
An: spr...@li...
Betreff: Re: [Springframework-developer] Retrieve all class path =
resources with the same name



I've been thinking about this, and though I had some doubts at first, I
definitely like "classpath*:" now, because of the * character.

The point is that ResourceLoader takes a location, while
ResourcePatternResolver takes a location _pattern_, and depending on the
place where you use a resource string, a location pattern may or may not
be allowed. In this regard it is important to think of
"classpath:beans.xml" as a location, and "classpath*:beans.xml" as a
location pattern.

Thus, a resource location always results in at most one matching file,
which is consistent with the way Resource and ResourceLoader are
defined.

I think we should clearly document that "classpath*:" is not considered
a prefix, but part of a location pattern, so its use is only allowed
where location patterns are allowed.

The implementation is tricky though. I suppose "classpath:*-beans.xml"
would work if the individual locations are resolvable to File, but what
about "classpath*:*-beans.xml"? Not that I would try to use a pattern
like that myself though ;-)

Kind regards,
Tom.

On Fri, 25 Jun 2004 09:25:00 +0200, "j=FCrgen h=F6ller [werk3AT]"
<jue...@we...> said:
> Any thoughts about the prefix naming? Is "classpath*:" for explictly
> wanting all matching classpath resources fine?
>=20
> Juergen
>=20
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
von
> j=FCrgen h=F6ller [werk3AT]
> Gesendet: Do 24.06.2004 09:56
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Retrieve all class path
> resources with the same name
>
>
>
> Colin,
>
> You do have a point there. We coul use a prefix like "classpath*:" for
> loading all matching resources from the classpath. ("resources:" is =
too
> general, IMO: It's about multiple _classpath_ resources.) That would =
keep
> the behavior of "classpath:" in any case, and allow to explicitly =
specify
> "I want all matching resources" via "classpath*:".
>
> Interestingly, a classpath resource string is the only resource =
location
> accepted by Spring's ResourceLoader that is not unique but can result =
in
> multiple matching files.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
von
> Colin Sampaleanu
> Gesendet: Do 24.06.2004 06:06
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Retrieve all class path
> resources with the same name
>
>
>
> I've been thinking about this, and was wondering if it's appropriate
> that _all_ matching resources are found, all the time, and also if we
> should be worried about a backwards incompatible change.
>
> Before, in ClassPathXmlApplicationContext, the locations
>    beans.xml
> and
>    classpath:beans.xml
> would return one resource, regardless of how many there were.
>
> Now the former still returns one, while the latter returns 1-x.
>
> Is it a problem that we've made a backwards incompatible change for =
the
> latter form?
> Is it a problem that somebody, if they want just one resource, has to
> know that they need to use the first form? Additionally to this, this
> distinction is possible when something like
> ClassPathXmlApplicationContext, but for others that override the =
default
> getResourceByPath to default to something else than a classpath
> resource,  it's not a possibility.
>
> I guess somebody could say, if there are multiple resources available
> under that name, is it ever appropriate to return just one? I think =
so,
> since after all, even in that case, the classloader resource loading
> strategy is well defined and deterministic.
>
> Since the 'classpath:' prefix is something we made up, why don't we =
keep
> this for just a single resource, and use something like 'resources:' =
(or
> whatever) to mean multiple resources?
>
> Colin
>
> j=FCrgen h=F6ller [werk3AT] wrote:
>
> >FYI, I've just refined PathMatchingResourcePatternResolver to be able =
to retrieve all class path resources with the same name. It actually =
inherits this from the new base class ClassPathResourcePatternResolver.
> >
> =
>http://sourceforge.net/forum/forum.php?thread_id=3D1096825&forum_id=3D25=
0340
> >
> >So "classpath:/beans.xml" will load all beans.xml files in classes =
directories or JAR files, if passed into =
PathMatchingResourcePatternResolver. Of course, Ant-style file path =
patterns like "/WEB-INF/*-context.xml" still work.
> >
> >As this is automatically used by "contextConfigLocation" parameters, =
this means that we can specify such a URL for a root web application =
context, for example to auto-load all beans.xml files contained in =
deployed JAR files in WEB-INF\lib (HiveMind-style)!
> >
> >Juergen
> >
> >
> >DI J=FCrgen H=F6ller
> >Senior System Architect
> >______________________________________
> >
> >werk3ATS - division systementwicklung
> >werk3AT informations- und mediensysteme
> >
> >europaplatz 4
> >A - 4020 linz
> >
> >t.  +43 (0) 732 71 65 29 502
> >f.  +43 (0) 732 71 65 29 3
> >mailto:jue...@we...
> >http://www.werk3at.com
> >______________________________________
> >werk3ATS - WIR ENTWICKELN ERFOLG
> >
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] do unit tests fail in CVS HEAD for others?

[Lee M. <lm...@ya...>]

I updated to the current CVS yesterday and saw the same errors from 'ant
tests'.  For some reason the lib/cglib/cglib-2.0.1.jar was still there
alongside the new cglib-2.0.2-dev.jar.  Once I deleted the 2.0.1 jar
everything worked fine with 'ant tests'.

-Lee

http://jroller.com/page/lmarlow

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
jas...@ma...
Sent: Friday, June 25, 2004 3:24 AM
To: spr...@li...
Subject: Re: [Springframework-developer] do unit tests fail in CVS HEAD for
others?


On 24 Jun 2004, at 13:46, Colin Sampaleanu wrote:
> Ok, I know what this is. The cglib version is not correct. We had to
> switch to a dev version of cglib to resolve some issues with cglib 
> based class proxy creation. The maven project file needs an override 
> to use cglib inside the lib dir istead of a stock cglib 2.0.1.
>
> I can probably make this change in about half an hour. In the meantime
> James, you may want to do it locally.

BTW thanks for the change Colin, the maven tests work perfectly for me 
now!

I still get the previous Ant error when I try 'ant tests' but I'm not 
gonna worry about that, I'll stick to the maven build.

Thanks again

James
-------
http://radio.weblogs.com/0112098/



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black
Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Retrieve all class path resources with the same name

[Tom T. <tom...@pr...>]

Another suggestion...

If we'd like to keep the prefix "classpath:" the same, maybe "all" could
be the default anyway, so "classpath:beans.xml" would load them all, and
"classpath:|beans.xml|" would load only one?

This would not be backwards compatible, but maybe that's acceptable, and
when using ClassPathXmlApplicationContext there would still be a
difference between "beans.xml" (loads one) and "classpath:beans.xml"
(loads all).

But if you're not using a prefix, you know you're relying on the
getResourceByPath provided by the specific ApplicationContext
implementation (and you presumably don't know which one that is), so you
wouldn't expect more than one result...
If you are using a "classpath:" prefix, you know you'll get all results,
except when using the "||" notation, which is probably pretty clear.

Regards,
Tom.

On Fri, 25 Jun 2004 10:43:43 -0400, "Colin Sampaleanu"
<col...@ex...> said:
> No, that wouldn't actually make sense, since * in the resource name=20
> (what comes after the 'classpath:' prefix), means an actual, 'glob'=20
> style wildcard. (which as I meantioned in another email, is not=20
> guaranteed to work, depending on whether the classes are actually on the=
=20
> filesystem or not).
>=20
>=20
> Matt Raible wrote:
>=20
> > classpath:* seems more intuitive to me - where its still using the=20=
=20
> > classpath: prefix
> >
> > On Jun 25, 2004, at 5:50 AM, Dmitriy Kopylenko wrote:
> >
> >> How about "classpath-all:" to be more explicit?
> >>
> >>  Dmitriy.
> >>
> >>  j=FCrgen h=F6ller [werk3AT] wrote:
> >> Any thoughts about the prefix naming? Is "classpath*:" for explictly=
=20=20
> >> wanting all matching classpath resources fine?
> >>
> >> Juergen
> >>
> >>
> >> ________________________________
> >>
> >> Von: spr...@li...  im=20
> >> Auftrag  von j=FCrgen h=F6ller [werk3AT]
> >> Gesendet: Do 24.06.2004 09:56
> >> An: spr...@li...
> >> Betreff: Re: [Springframework-developer] Retrieve all class path=20=20
> >> resources with the same name
> >>
> >>
> >>
> >> Colin,
> >>
> >> You do have a point there. We coul use a prefix like "classpath*:"=20
> >> for  loading all matching resources from the classpath. ("resources:"=
=20
> >> is  too general, IMO: It's about multiple _classpath_ resources.)=20
> >> That  would keep the behavior of "classpath:" in any case, and allow=
=20
> >> to  explicitly specify "I want all matching resources" via=20
> >> "classpath*:".
> >>
> >> Interestingly, a classpath resource string is the only resource=20=20
> >> location accepted by Spring's ResourceLoader that is not unique but=20=
=20
> >> can result in multiple matching files.
> >>
> >> Juergen
> >>
> >>
> >> ________________________________
> >>
> >> Von: spr...@li...  im=20
> >> Auftrag  von Colin Sampaleanu
> >> Gesendet: Do 24.06.2004 06:06
> >> An: spr...@li...
> >> Betreff: Re: [Springframework-developer] Retrieve all class path=20=20
> >> resources with the same name
> >>
> >>
> >>
> >> I've been thinking about this, and was wondering if it's appropriate
> >> that _all_ matching resources are found, all the time, and also if we
> >> should be worried about a backwards incompatible change.
> >>
> >> Before, in ClassPathXmlApplicationContext, the locations
> >>    beans.xml
> >> and
> >>    classpath:beans.xml
> >> would return one resource, regardless of how many there were.
> >>
> >> Now the former still returns one, while the latter returns 1-x.
> >>
> >> Is it a problem that we've made a backwards incompatible change for the
> >> latter form?
> >> Is it a problem that somebody, if they want just one resource, has to
> >> know that they need to use the first form? Additionally to this, this
> >> distinction is possible when something like
> >> ClassPathXmlApplicationContext, but for others that override the=20=20
> >> default
> >> getResourceByPath to default to something else than a classpath
> >> resource,  it's not a possibility.
> >>
> >> I guess somebody could say, if there are multiple resources available
> >> under that name, is it ever appropriate to return just one? I think so,
> >> since after all, even in that case, the classloader resource loading
> >> strategy is well defined and deterministic.
> >>
> >> Since the 'classpath:' prefix is something we made up, why don't we=20=
=20
> >> keep
> >> this for just a single resource, and use something like 'resources:'=
=20=20
> >> (or
> >> whatever) to mean multiple resources?
> >>
> >> Colin
> >>
> >> j=FCrgen h=F6ller [werk3AT] wrote:
> >>
> >>
> >> FYI, I've just refined PathMatchingResourcePatternResolver to be=20
> >> able  to retrieve all class path resources with the same name. It=20
> >> actually  inherits this from the new base class=20=20
> >> ClassPathResourcePatternResolver.
> >>
> >>   http://sourceforge.net/forum/forum.php?=20
> >> thread_id=3D1096825&forum_id=3D250340
> >>
> >> So "classpath:/beans.xml" will load all beans.xml files in classes=20=
=20
> >> directories or JAR files, if passed into=20=20
> >> PathMatchingResourcePatternResolver. Of course, Ant-style file path=20=
=20
> >> patterns like "/WEB-INF/*-context.xml" still work.
> >>
> >> As this is automatically used by "contextConfigLocation" parameters,=
=20=20
> >> this means that we can specify such a URL for a root web application=
=20=20
> >> context, for example to auto-load all beans.xml files contained in=20=
=20
> >> deployed JAR files in WEB-INF\lib (HiveMind-style)!
> >>
> >> Juergen
> >>
> >>
> >> DI J=FCrgen H=F6ller
> >> Senior System Architect
> >> ______________________________________
> >>
> >> werk3ATS - division systementwicklung
> >> werk3AT informations- und mediensysteme
> >>
> >> europaplatz 4
> >> A - 4020 linz
> >>
> >> t.  +43 (0) 732 71 65 29 502
> >> f.  +43 (0) 732 71 65 29 3
> >>  mailto:jue...@we...
> >>  http://www.werk3at.com
> >> ______________________________________
> >> werk3ATS - WIR ENTWICKELN ERFOLG
> >>
> >>
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.Net email sponsored by Black Hat Briefings & Training.
> >> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> >> digital self defense, top technical experts, no vendor pitches,
> >> unmatched networking opportunities. Visit www.blackhat.com
> >> _______________________________________________
> >> Springframework-developer mailing list
> >>  Spr...@li...
> >>  https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.Net email sponsored by Black Hat Briefings & Training.
> >> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> >> digital self defense, top technical experts, no vendor pitches,
> >> unmatched networking opportunities. Visit www.blackhat.com
> >> _______________________________________________
> >> Springframework-developer mailing list
> >>  Spr...@li...
> >>  https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.Net email sponsored by Black Hat Briefings & Training.
> >> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> >> digital self defense, top technical experts, no vendor pitches,
> >> unmatched networking opportunities. Visit www.blackhat.com
> >> _______________________________________________
> >> Springframework-developer mailing list
> >>  Spr...@li...
> >>  https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
> digital self defense, top technical experts, no vendor pitches,=20
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] OpenSessionInViewFilter ideas

[Norris, T. <tys...@be...>]

The typical use case for accessing a session after rollback is accessing
read-only data which should be available regardless of any transaction
success or failure.=20

Specifically, we have various data that is used to customize the
navigation framework of our webapp. I won't argue that its not efficient
to look it up with each request, but there is nothing technically wrong
with it.

Currently, the session opened in OpenSessionInViewFilter will be used
within the transaction, which causes problems for rollbacks (and even
commits for some unfortunate enough to use weblogic :). The problem
being that after rollback or commit, the navigation data access fails
because the connection is now defunct.

Yes, our app is currently architected to use certain methods as
transactional units, with all of them using "REQUIRES" propagation (some
EJB, some spring/hibernate). We could potentially avoid this problem by
using "REQUIRES_NEW", and have the filter create a new tx (instead of
just open a session) which will affect the datasource behavior in
regards to the transaction, but this breaks the potential interaction of
many of these methods - there should only be 1 transaction per request.
In this way, you could say it's a "nested tx problem", but only in that
we can't use "true nested tx", and requires_new is not useable for us
either.

Session.clear() would help in the case where the lazy-loading-data is
accessed *after* any transactional behavior, but NOT in the case where
data is accessed *before* the transaction. I would rather not force
specific ordering with regards to transactional methods and
lazy-loading-dependent methods.

Let me know what you think

Tyson


-----Original Message-----
From: James Cook [mailto:jim...@do...]=20
Sent: Friday, June 25, 2004 6:37 AM
To: spr...@li...
Subject: RE: [Springframework-developer] OpenSessionInViewFilter ideas

I was wondering (out loud) if Hibernate's session.clear() couldn't be
used
to "reinitialize" its session for continuing work after a rollback or
exception? I suppose if a rollback invalidates the datasource from
further
activity on certain platforms that it wouldn't matter if Hibernate could
recover on its own.

For many that currently need this feature, I suppose they are
architecting
their application to use SAO methods as their transactional units. If a
rollback occurs, it occurs only in the scope of the SAO method call.
They
would also have to "exercise" their business objects in order to load
lazy
collections in the SAO instead of the web tier.

I don't mean to minimize the goal you are trying to achieve, but what
are
some use cases where a developer needs to reuse a session after a
rollback?
Is this in relation to nested transactions?


> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On
Behalf
> Of Norris, Tyson
> Sent: Thursday, June 24, 2004 9:04 PM
> To: spr...@li...
> Subject: [Springframework-developer] OpenSessionInViewFilter ideas
>=20
> Hi Folks -
> We have been running into problems with migrating an existing CMT EJB
> application to use OpenSessionInViewFilter, and here are a couple
> thoughts on the subject.
>=20
> The basic problem is that when a session is created, then a
transaction
> is initiated and uses that session, if the transaction rolls back, how
> can we still access the initial session created in the filter?
>=20
> Currently the same session is used after entering the transaction.
This
> is a problem for us using weblogic, since weblogic datasource become
> useless after a transaction rolls back (or commits), but I think this
is
> also general practice for hibernate users to close the session on
> rollback:
> "If you rollback the transaction you should immediately close and
> discard the current session to ensure that Hibernate's internal state
is
> consistent."
>=20
> So, what to do? Would it be desirable to build into
SessionFactoryUtils
> the ability to generate a new session for each new transaction?
>=20
> I have worked around the problem temporarily by "manually" doing this.
> That is, I check for an existing JTA transaction, and if its their,
> register a new synchronization that holds a reference to the session
> opened with the OpenSessionInViewFilter, and the
> TransactionSynchronizationManager's session is unbound. When the
> transaction completes, TransactionSynchronizationManager session is
> re-bound, and non-transactional data access can proceed after the
commit
> or rollback.
>=20
> This of course presents a potential problem of loading the same data
in
> multiple sessions, but this may be negligible for many cases.
>=20
> Is this something worth adding as an additional parameter to
> SessionFactoryUtils.getSession()? When specified (true), if an
existing
> SessionHolder is found, if not already synchronized with a
transaction,
> it would be replaced with a new session, then restored after the
> transaction completes.
>=20
> Let me know what you think. Or if there is a better alternative, I'm
all
> ears :)
>=20
> Thanks
> tyson
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
digital self defense, top technical experts, no vendor pitches,=20
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Retrieve all class path resources with the same name

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

No, that wouldn't actually make sense, since * in the resource name 
(what comes after the 'classpath:' prefix), means an actual, 'glob' 
style wildcard. (which as I meantioned in another email, is not 
guaranteed to work, depending on whether the classes are actually on the 
filesystem or not).


Matt Raible wrote:

> classpath:* seems more intuitive to me - where its still using the  
> classpath: prefix
>
> On Jun 25, 2004, at 5:50 AM, Dmitriy Kopylenko wrote:
>
>> How about "classpath-all:" to be more explicit?
>>
>>  Dmitriy.
>>
>>  jürgen höller [werk3AT] wrote:
>> Any thoughts about the prefix naming? Is "classpath*:" for explictly  
>> wanting all matching classpath resources fine?
>>
>> Juergen
>>
>>
>> ________________________________
>>
>> Von: spr...@li...  im 
>> Auftrag  von jürgen höller [werk3AT]
>> Gesendet: Do 24.06.2004 09:56
>> An: spr...@li...
>> Betreff: Re: [Springframework-developer] Retrieve all class path  
>> resources with the same name
>>
>>
>>
>> Colin,
>>
>> You do have a point there. We coul use a prefix like "classpath*:" 
>> for  loading all matching resources from the classpath. ("resources:" 
>> is  too general, IMO: It's about multiple _classpath_ resources.) 
>> That  would keep the behavior of "classpath:" in any case, and allow 
>> to  explicitly specify "I want all matching resources" via 
>> "classpath*:".
>>
>> Interestingly, a classpath resource string is the only resource  
>> location accepted by Spring's ResourceLoader that is not unique but  
>> can result in multiple matching files.
>>
>> Juergen
>>
>>
>> ________________________________
>>
>> Von: spr...@li...  im 
>> Auftrag  von Colin Sampaleanu
>> Gesendet: Do 24.06.2004 06:06
>> An: spr...@li...
>> Betreff: Re: [Springframework-developer] Retrieve all class path  
>> resources with the same name
>>
>>
>>
>> I've been thinking about this, and was wondering if it's appropriate
>> that _all_ matching resources are found, all the time, and also if we
>> should be worried about a backwards incompatible change.
>>
>> Before, in ClassPathXmlApplicationContext, the locations
>>    beans.xml
>> and
>>    classpath:beans.xml
>> would return one resource, regardless of how many there were.
>>
>> Now the former still returns one, while the latter returns 1-x.
>>
>> Is it a problem that we've made a backwards incompatible change for the
>> latter form?
>> Is it a problem that somebody, if they want just one resource, has to
>> know that they need to use the first form? Additionally to this, this
>> distinction is possible when something like
>> ClassPathXmlApplicationContext, but for others that override the  
>> default
>> getResourceByPath to default to something else than a classpath
>> resource,  it's not a possibility.
>>
>> I guess somebody could say, if there are multiple resources available
>> under that name, is it ever appropriate to return just one? I think so,
>> since after all, even in that case, the classloader resource loading
>> strategy is well defined and deterministic.
>>
>> Since the 'classpath:' prefix is something we made up, why don't we  
>> keep
>> this for just a single resource, and use something like 'resources:'  
>> (or
>> whatever) to mean multiple resources?
>>
>> Colin
>>
>> jürgen höller [werk3AT] wrote:
>>
>>
>> FYI, I've just refined PathMatchingResourcePatternResolver to be 
>> able  to retrieve all class path resources with the same name. It 
>> actually  inherits this from the new base class  
>> ClassPathResourcePatternResolver.
>>
>>   http://sourceforge.net/forum/forum.php? 
>> thread_id=1096825&forum_id=250340
>>
>> So "classpath:/beans.xml" will load all beans.xml files in classes  
>> directories or JAR files, if passed into  
>> PathMatchingResourcePatternResolver. Of course, Ant-style file path  
>> patterns like "/WEB-INF/*-context.xml" still work.
>>
>> As this is automatically used by "contextConfigLocation" parameters,  
>> this means that we can specify such a URL for a root web application  
>> context, for example to auto-load all beans.xml files contained in  
>> deployed JAR files in WEB-INF\lib (HiveMind-style)!
>>
>> Juergen
>>
>>
>> DI Jürgen Höller
>> Senior System Architect
>> ______________________________________
>>
>> werk3ATS - division systementwicklung
>> werk3AT informations- und mediensysteme
>>
>> europaplatz 4
>> A - 4020 linz
>>
>> t.  +43 (0) 732 71 65 29 502
>> f.  +43 (0) 732 71 65 29 3
>>  mailto:jue...@we...
>>  http://www.werk3at.com
>> ______________________________________
>> werk3ATS - WIR ENTWICKELN ERFOLG
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by Black Hat Briefings & Training.
>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>> digital self defense, top technical experts, no vendor pitches,
>> unmatched networking opportunities. Visit www.blackhat.com
>> _______________________________________________
>> Springframework-developer mailing list
>>  Spr...@li...
>>  https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by Black Hat Briefings & Training.
>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>> digital self defense, top technical experts, no vendor pitches,
>> unmatched networking opportunities. Visit www.blackhat.com
>> _______________________________________________
>> Springframework-developer mailing list
>>  Spr...@li...
>>  https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by Black Hat Briefings & Training.
>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>> digital self defense, top technical experts, no vendor pitches,
>> unmatched networking opportunities. Visit www.blackhat.com
>> _______________________________________________
>> Springframework-developer mailing list
>>  Spr...@li...
>>  https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Retrieve all class path resources with the same name

[Matt R. <li...@ra...>]

classpath:* seems more intuitive to me - where its still using the =20
classpath: prefix

On Jun 25, 2004, at 5:50 AM, Dmitriy Kopylenko wrote:

> How about "classpath-all:" to be more explicit?
>
>  Dmitriy.
>
>  j=FCrgen h=F6ller [werk3AT] wrote:
> Any thoughts about the prefix naming? Is "classpath*:" for explictly =20=

> wanting all matching classpath resources fine?
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li...  im Auftrag =
=20
> von j=FCrgen h=F6ller [werk3AT]
> Gesendet: Do 24.06.2004 09:56
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Retrieve all class path =20
> resources with the same name
>
>
>
> Colin,
>
> You do have a point there. We coul use a prefix like "classpath*:" for =
=20
> loading all matching resources from the classpath. ("resources:" is =20=

> too general, IMO: It's about multiple _classpath_ resources.) That =20
> would keep the behavior of "classpath:" in any case, and allow to =20
> explicitly specify "I want all matching resources" via "classpath*:".
>
> Interestingly, a classpath resource string is the only resource =20
> location accepted by Spring's ResourceLoader that is not unique but =20=

> can result in multiple matching files.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li...  im Auftrag =
=20
> von Colin Sampaleanu
> Gesendet: Do 24.06.2004 06:06
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Retrieve all class path =20
> resources with the same name
>
>
>
> I've been thinking about this, and was wondering if it's appropriate
> that _all_ matching resources are found, all the time, and also if we
> should be worried about a backwards incompatible change.
>
> Before, in ClassPathXmlApplicationContext, the locations
>    beans.xml
> and
>    classpath:beans.xml
> would return one resource, regardless of how many there were.
>
> Now the former still returns one, while the latter returns 1-x.
>
> Is it a problem that we've made a backwards incompatible change for =
the
> latter form?
> Is it a problem that somebody, if they want just one resource, has to
> know that they need to use the first form? Additionally to this, this
> distinction is possible when something like
> ClassPathXmlApplicationContext, but for others that override the =20
> default
> getResourceByPath to default to something else than a classpath
> resource,  it's not a possibility.
>
> I guess somebody could say, if there are multiple resources available
> under that name, is it ever appropriate to return just one? I think =
so,
> since after all, even in that case, the classloader resource loading
> strategy is well defined and deterministic.
>
> Since the 'classpath:' prefix is something we made up, why don't we =20=

> keep
> this for just a single resource, and use something like 'resources:' =20=

> (or
> whatever) to mean multiple resources?
>
> Colin
>
> j=FCrgen h=F6ller [werk3AT] wrote:
>
>
> FYI, I've just refined PathMatchingResourcePatternResolver to be able =20=

> to retrieve all class path resources with the same name. It actually =20=

> inherits this from the new base class =20
> ClassPathResourcePatternResolver.
>
>  =20
> http://sourceforge.net/forum/forum.php?=20
> thread_id=3D1096825&forum_id=3D250340
>
> So "classpath:/beans.xml" will load all beans.xml files in classes =20
> directories or JAR files, if passed into =20
> PathMatchingResourcePatternResolver. Of course, Ant-style file path =20=

> patterns like "/WEB-INF/*-context.xml" still work.
>
> As this is automatically used by "contextConfigLocation" parameters, =20=

> this means that we can specify such a URL for a root web application =20=

> context, for example to auto-load all beans.xml files contained in =20
> deployed JAR files in WEB-INF\lib (HiveMind-style)!
>
> Juergen
>
>
> DI J=FCrgen H=F6ller
> Senior System Architect
> ______________________________________
>
> werk3ATS - division systementwicklung
> werk3AT informations- und mediensysteme
>
> europaplatz 4
> A - 4020 linz
>
> t.  +43 (0) 732 71 65 29 502
> f.  +43 (0) 732 71 65 29 3
>  mailto:jue...@we...
>  http://www.werk3at.com
> ______________________________________
> werk3ATS - WIR ENTWICKELN ERFOLG
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
>  Spr...@li...
>  =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
>  Spr...@li...
>  =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
>  Spr...@li...
>  =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> =20=

RE: [Springframework-developer] IoC container enhancements

[James C. <jim...@do...>]

Since you are enhancing the injection support for the container, do you
think it is worthwhile adding syntax to support Type 1 (Interface Injection)
IoC?

http://opensource.atlassian.com/confluence/spring/display/DISC/Adding+Interf
ace+Injection+to+Spring




> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Rod Johnson
> Sent: Friday, June 25, 2004 3:50 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] IoC container enhancements
> 
> > Lookup methods can be combined with Setter Injection. They
> > can't presently be combined with Constructor Injection, but I
> > will add support for this, assuming that it's possible with
> > CGLIB.
> 
> 
> I've just removed this restriction.
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] OpenSessionInViewFilter ideas

[James C. <jim...@do...>]

I was wondering (out loud) if Hibernate's session.clear() couldn't be used
to "reinitialize" its session for continuing work after a rollback or
exception? I suppose if a rollback invalidates the datasource from further
activity on certain platforms that it wouldn't matter if Hibernate could
recover on its own.

For many that currently need this feature, I suppose they are architecting
their application to use SAO methods as their transactional units. If a
rollback occurs, it occurs only in the scope of the SAO method call. They
would also have to "exercise" their business objects in order to load lazy
collections in the SAO instead of the web tier.

I don't mean to minimize the goal you are trying to achieve, but what are
some use cases where a developer needs to reuse a session after a rollback?
Is this in relation to nested transactions?


> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Norris, Tyson
> Sent: Thursday, June 24, 2004 9:04 PM
> To: spr...@li...
> Subject: [Springframework-developer] OpenSessionInViewFilter ideas
> 
> Hi Folks -
> We have been running into problems with migrating an existing CMT EJB
> application to use OpenSessionInViewFilter, and here are a couple
> thoughts on the subject.
> 
> The basic problem is that when a session is created, then a transaction
> is initiated and uses that session, if the transaction rolls back, how
> can we still access the initial session created in the filter?
> 
> Currently the same session is used after entering the transaction. This
> is a problem for us using weblogic, since weblogic datasource become
> useless after a transaction rolls back (or commits), but I think this is
> also general practice for hibernate users to close the session on
> rollback:
> "If you rollback the transaction you should immediately close and
> discard the current session to ensure that Hibernate's internal state is
> consistent."
> 
> So, what to do? Would it be desirable to build into SessionFactoryUtils
> the ability to generate a new session for each new transaction?
> 
> I have worked around the problem temporarily by "manually" doing this.
> That is, I check for an existing JTA transaction, and if its their,
> register a new synchronization that holds a reference to the session
> opened with the OpenSessionInViewFilter, and the
> TransactionSynchronizationManager's session is unbound. When the
> transaction completes, TransactionSynchronizationManager session is
> re-bound, and non-transactional data access can proceed after the commit
> or rollback.
> 
> This of course presents a potential problem of loading the same data in
> multiple sessions, but this may be negligible for many cases.
> 
> Is this something worth adding as an additional parameter to
> SessionFactoryUtils.getSession()? When specified (true), if an existing
> SessionHolder is found, if not already synchronized with a transaction,
> it would be replaced with a new session, then restored after the
> transaction completes.
> 
> Let me know what you think. Or if there is a better alternative, I'm all
> ears :)
> 
> Thanks
> tyson
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Retrieve all class path resources with the same name

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

Juergen, I am ok with this.    As an aside, I think there is the 
potential for confusion on some people's part in that classpath*: can 
find multiple resources, while the equivalent path with classpath: 
won't, while classpath:xxxxx* can also find multiple paths in _some_ 
environments (of course the actual files will have different names 
here). I'm not sure people should ever really rely on the latter. It 
assumes that the classpath is actually available on the filesystem, and 
is not really a safe assumption, as it varies so much from app server to 
app server. People are also in general not used to dealing with 
classpath resources with wildcards...

Colin

jürgen höller [werk3AT] wrote:

>Any thoughts about the prefix naming? Is "classpath*:" for explictly wanting all matching classpath resources fine?
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
>Gesendet: Do 24.06.2004 09:56
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Retrieve all class path resources with the same name
>
>
>
>Colin,
>
>You do have a point there. We coul use a prefix like "classpath*:" for loading all matching resources from the classpath. ("resources:" is too general, IMO: It's about multiple _classpath_ resources.) That would keep the behavior of "classpath:" in any case, and allow to explicitly specify "I want all matching resources" via "classpath*:".
>
>Interestingly, a classpath resource string is the only resource location accepted by Spring's ResourceLoader that is not unique but can result in multiple matching files.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: Do 24.06.2004 06:06
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Retrieve all class path resources with the same name
>
>
>
>I've been thinking about this, and was wondering if it's appropriate
>that _all_ matching resources are found, all the time, and also if we
>should be worried about a backwards incompatible change.
>
>Before, in ClassPathXmlApplicationContext, the locations
>   beans.xml
>and
>   classpath:beans.xml
>would return one resource, regardless of how many there were.
>
>Now the former still returns one, while the latter returns 1-x.
>
>Is it a problem that we've made a backwards incompatible change for the
>latter form?
>Is it a problem that somebody, if they want just one resource, has to
>know that they need to use the first form? Additionally to this, this
>distinction is possible when something like
>ClassPathXmlApplicationContext, but for others that override the default
>getResourceByPath to default to something else than a classpath
>resource,  it's not a possibility.
>
>I guess somebody could say, if there are multiple resources available
>under that name, is it ever appropriate to return just one? I think so,
>since after all, even in that case, the classloader resource loading
>strategy is well defined and deterministic.
>
>Since the 'classpath:' prefix is something we made up, why don't we keep
>this for just a single resource, and use something like 'resources:' (or
>whatever) to mean multiple resources?
>
>Colin
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>FYI, I've just refined PathMatchingResourcePatternResolver to be able to retrieve all class path resources with the same name. It actually inherits this from the new base class ClassPathResourcePatternResolver.
>>
>>http://sourceforge.net/forum/forum.php?thread_id=1096825&forum_id=250340
>>
>>So "classpath:/beans.xml" will load all beans.xml files in classes directories or JAR files, if passed into PathMatchingResourcePatternResolver. Of course, Ant-style file path patterns like "/WEB-INF/*-context.xml" still work.
>>
>>As this is automatically used by "contextConfigLocation" parameters, this means that we can specify such a URL for a root web application context, for example to auto-load all beans.xml files contained in deployed JAR files in WEB-INF\lib (HiveMind-style)!
>>
>>Juergen
>>    
>>

Re: [Springframework-developer] Retrieve all class path resources with the same name

[Dmitriy K. <dko...@ru...>]

How about "classpath-all:" to be more explicit?

Dmitriy.

jürgen höller [werk3AT] wrote:

>Any thoughts about the prefix naming? Is "classpath*:" for explictly wanting all matching classpath resources fine?
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
>Gesendet: Do 24.06.2004 09:56
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Retrieve all class path resources with the same name
>
>
>
>Colin,
>
>You do have a point there. We coul use a prefix like "classpath*:" for loading all matching resources from the classpath. ("resources:" is too general, IMO: It's about multiple _classpath_ resources.) That would keep the behavior of "classpath:" in any case, and allow to explicitly specify "I want all matching resources" via "classpath*:".
>
>Interestingly, a classpath resource string is the only resource location accepted by Spring's ResourceLoader that is not unique but can result in multiple matching files.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: Do 24.06.2004 06:06
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Retrieve all class path resources with the same name
>
>
>
>I've been thinking about this, and was wondering if it's appropriate
>that _all_ matching resources are found, all the time, and also if we
>should be worried about a backwards incompatible change.
>
>Before, in ClassPathXmlApplicationContext, the locations
>   beans.xml
>and
>   classpath:beans.xml
>would return one resource, regardless of how many there were.
>
>Now the former still returns one, while the latter returns 1-x.
>
>Is it a problem that we've made a backwards incompatible change for the
>latter form?
>Is it a problem that somebody, if they want just one resource, has to
>know that they need to use the first form? Additionally to this, this
>distinction is possible when something like
>ClassPathXmlApplicationContext, but for others that override the default
>getResourceByPath to default to something else than a classpath
>resource,  it's not a possibility.
>
>I guess somebody could say, if there are multiple resources available
>under that name, is it ever appropriate to return just one? I think so,
>since after all, even in that case, the classloader resource loading
>strategy is well defined and deterministic.
>
>Since the 'classpath:' prefix is something we made up, why don't we keep
>this for just a single resource, and use something like 'resources:' (or
>whatever) to mean multiple resources?
>
>Colin
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>FYI, I've just refined PathMatchingResourcePatternResolver to be able to retrieve all class path resources with the same name. It actually inherits this from the new base class ClassPathResourcePatternResolver.
>>
>>http://sourceforge.net/forum/forum.php?thread_id=1096825&forum_id=250340
>>
>>So "classpath:/beans.xml" will load all beans.xml files in classes directories or JAR files, if passed into PathMatchingResourcePatternResolver. Of course, Ant-style file path patterns like "/WEB-INF/*-context.xml" still work.
>>
>>As this is automatically used by "contextConfigLocation" parameters, this means that we can specify such a URL for a root web application context, for example to auto-load all beans.xml files contained in deployed JAR files in WEB-INF\lib (HiveMind-style)!
>>
>>Juergen
>>
>>
>>DI Jürgen Höller
>>Senior System Architect
>>______________________________________
>>
>>werk3ATS - division systementwicklung
>>werk3AT informations- und mediensysteme
>>
>>europaplatz 4
>>A - 4020 linz
>>
>>t.  +43 (0) 732 71 65 29 502
>>f.  +43 (0) 732 71 65 29 3
>>mailto:jue...@we...
>>http://www.werk3at.com
>>______________________________________
>>werk3ATS - WIR ENTWICKELN ERFOLG
>>
>>
>>    
>>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>digital self defense, top technical experts, no vendor pitches,
>unmatched networking opportunities. Visit www.blackhat.com
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>digital self defense, top technical experts, no vendor pitches,
>unmatched networking opportunities. Visit www.blackhat.com
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
>digital self defense, top technical experts, no vendor pitches, 
>unmatched networking opportunities. Visit www.blackhat.com
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

Re: [Springframework-developer] RE: Not leveraging the CGLIB cache

[Rob H. <ro...@ca...>]

Yes using the equalsInProxy method means that the target has an effect 
on whether or not the proxy class is reused when really is shouldn't 
have that much of a say. I refactored AopProxyUtils.equalsInProxy 
moving some of the logic into separate methods, which I now use for the 
comparison in ProxyCallbackFilter,equals. I updated the test to test 
when the targets are different and it now passes. The comparison in 
ProxyCallbackFilter comapres the advisors and proxied interfaces along 
with the frozen, targetsource.static and exposeproxy flags. If all 
these are the same then the proxy class will be reused.

Tyson, I committed this update - give it a try!
Rob

On 25 Jun 2004, at 00:34, Chris Nokleberg wrote:

> Norris, Tyson wrote:
>> (Using the CVS version 1.8 Cglib2ApoProxy) I get everything to work 
>> fine
>> with the test case I mentioned below even when both proxies are 
>> advised,
>> unless I remove the equals() method from TestBean.
> [snip]
>> So, my question is - why should this affect whether CGLIB can cache 
>> the
>> generated class? I'm back to not understanding if the problem is in
>> CGLIB, or Cglib2AopProxy. (or, maybe I'm missing some understanding, 
>> and
>> the equals method on my beans truly is required...)
>
> The new ProxyCallbackFilter class still uses 
> AopProxyUtils.equalsInProxy in
> its equals method. equalsInProxy uses equality of the AdvisedSupport
> TargetSource. Depending on the implementation of TargetSource being 
> used, I
> think this means it *is* possible for your target bean's equals method 
> to
> affect CGLIB caching behavior. I'm not qualified to say whether this is
> desirable or not.
>
> Chris
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Retrieve all class path resources with the same name

[Tom T. <tom...@pr...>]

I've been thinking about this, and though I had some doubts at first, I
definitely like "classpath*:" now, because of the * character.

The point is that ResourceLoader takes a location, while
ResourcePatternResolver takes a location _pattern_, and depending on the
place where you use a resource string, a location pattern may or may not
be allowed. In this regard it is important to think of
"classpath:beans.xml" as a location, and "classpath*:beans.xml" as a
location pattern.

Thus, a resource location always results in at most one matching file,
which is consistent with the way Resource and ResourceLoader are
defined.

I think we should clearly document that "classpath*:" is not considered
a prefix, but part of a location pattern, so its use is only allowed
where location patterns are allowed.

The implementation is tricky though. I suppose "classpath:*-beans.xml"
would work if the individual locations are resolvable to File, but what
about "classpath*:*-beans.xml"? Not that I would try to use a pattern
like that myself though ;-)

Kind regards,
Tom.

On Fri, 25 Jun 2004 09:25:00 +0200, "j=FCrgen h=F6ller [werk3AT]"
<jue...@we...> said:
> Any thoughts about the prefix naming? Is "classpath*:" for explictly
> wanting all matching classpath resources fine?
>=20=20
> Juergen
>=20=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag von
> j=FCrgen h=F6ller [werk3AT]
> Gesendet: Do 24.06.2004 09:56
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Retrieve all class path
> resources with the same name
>=20
>=20
>=20
> Colin,
>=20
> You do have a point there. We coul use a prefix like "classpath*:" for
> loading all matching resources from the classpath. ("resources:" is too
> general, IMO: It's about multiple _classpath_ resources.) That would keep
> the behavior of "classpath:" in any case, and allow to explicitly specify
> "I want all matching resources" via "classpath*:".
>=20
> Interestingly, a classpath resource string is the only resource location
> accepted by Spring's ResourceLoader that is not unique but can result in
> multiple matching files.
>=20
> Juergen
>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag von
> Colin Sampaleanu
> Gesendet: Do 24.06.2004 06:06
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Retrieve all class path
> resources with the same name
>=20
>=20
>=20
> I've been thinking about this, and was wondering if it's appropriate
> that _all_ matching resources are found, all the time, and also if we
> should be worried about a backwards incompatible change.
>=20
> Before, in ClassPathXmlApplicationContext, the locations
>    beans.xml
> and
>    classpath:beans.xml
> would return one resource, regardless of how many there were.
>=20
> Now the former still returns one, while the latter returns 1-x.
>=20
> Is it a problem that we've made a backwards incompatible change for the
> latter form?
> Is it a problem that somebody, if they want just one resource, has to
> know that they need to use the first form? Additionally to this, this
> distinction is possible when something like
> ClassPathXmlApplicationContext, but for others that override the default
> getResourceByPath to default to something else than a classpath
> resource,  it's not a possibility.
>=20
> I guess somebody could say, if there are multiple resources available
> under that name, is it ever appropriate to return just one? I think so,
> since after all, even in that case, the classloader resource loading
> strategy is well defined and deterministic.
>=20
> Since the 'classpath:' prefix is something we made up, why don't we keep
> this for just a single resource, and use something like 'resources:' (or
> whatever) to mean multiple resources?
>=20
> Colin
>=20
> j=FCrgen h=F6ller [werk3AT] wrote:
>=20
> >FYI, I've just refined PathMatchingResourcePatternResolver to be able to=
 retrieve all class path resources with the same name. It actually inherits=
 this from the new base class ClassPathResourcePatternResolver.
> >
> >http://sourceforge.net/forum/forum.php?thread_id=3D1096825&forum_id=3D25=
0340
> >
> >So "classpath:/beans.xml" will load all beans.xml files in classes direc=
tories or JAR files, if passed into PathMatchingResourcePatternResolver. Of=
 course, Ant-style file path patterns like "/WEB-INF/*-context.xml" still w=
ork.
> >
> >As this is automatically used by "contextConfigLocation" parameters, thi=
s means that we can specify such a URL for a root web application context, =
for example to auto-load all beans.xml files contained in deployed JAR file=
s in WEB-INF\lib (HiveMind-style)!
> >
> >Juergen
> >
> >
> >DI J=FCrgen H=F6ller
> >Senior System Architect
> >______________________________________
> >
> >werk3ATS - division systementwicklung
> >werk3AT informations- und mediensysteme
> >
> >europaplatz 4
> >A - 4020 linz
> >
> >t.  +43 (0) 732 71 65 29 502
> >f.  +43 (0) 732 71 65 29 3
> >mailto:jue...@we...
> >http://www.werk3at.com
> >______________________________________
> >werk3ATS - WIR ENTWICKELN ERFOLG
> >
> >
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] do unit tests fail in CVS HEAD for others?

[<jas...@ma...>]

On 24 Jun 2004, at 13:46, Colin Sampaleanu wrote:
> Ok, I know what this is. The cglib version is not correct. We had to 
> switch to a dev version of cglib to resolve some issues with cglib 
> based class proxy creation. The maven project file needs an override 
> to use cglib inside the lib dir istead of a stock cglib 2.0.1.
>
> I can probably make this change in about half an hour. In the meantime 
> James, you may want to do it locally.

BTW thanks for the change Colin, the maven tests work perfectly for me 
now!

I still get the previous Ant error when I try 'ant tests' but I'm not 
gonna worry about that, I'll stick to the maven build.

Thanks again

James
-------
http://radio.weblogs.com/0112098/

Re: [Springframework-developer] IoC container enhancements

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

> Lookup methods can be combined with Setter Injection. They 
> can't presently be combined with Constructor Injection, but I 
> will add support for this, assuming that it's possible with 
> CGLIB.
 

I've just removed this restriction. 

[Springframework-developer] Re: Not leveraging the CGLIB cache

[Rob H. <ro...@ca...>]

I'll check that out and see if it needs revising. I think as long as the 
advisors are the same then the same proxy class can be used. I will look 
into this some more today.

Rob 


Chris Nokleberg writes: 

> Norris, Tyson wrote:
>> (Using the CVS version 1.8 Cglib2ApoProxy) I get everything to work fine
>> with the test case I mentioned below even when both proxies are advised,
>> unless I remove the equals() method from TestBean.
> [snip]
>> So, my question is - why should this affect whether CGLIB can cache the
>> generated class? I'm back to not understanding if the problem is in
>> CGLIB, or Cglib2AopProxy. (or, maybe I'm missing some understanding, and
>> the equals method on my beans truly is required...)
> 
> The new ProxyCallbackFilter class still uses AopProxyUtils.equalsInProxy in
> its equals method. equalsInProxy uses equality of the AdvisedSupport
> TargetSource. Depending on the implementation of TargetSource being used, I
> think this means it *is* possible for your target bean's equals method to
> affect CGLIB caching behavior. I'm not qualified to say whether this is
> desirable or not. 
> 
> Chris 
> 
>  
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
 

Re: [Springframework-developer] Retrieve all class path resources with the same name

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

Any thoughts about the prefix naming? Is "classpath*:" for explictly =
wanting all matching classpath resources fine?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Do 24.06.2004 09:56
An: spr...@li...
Betreff: Re: [Springframework-developer] Retrieve all class path =
resources with the same name



Colin,

You do have a point there. We coul use a prefix like "classpath*:" for =
loading all matching resources from the classpath. ("resources:" is too =
general, IMO: It's about multiple _classpath_ resources.) That would =
keep the behavior of "classpath:" in any case, and allow to explicitly =
specify "I want all matching resources" via "classpath*:".

Interestingly, a classpath resource string is the only resource location =
accepted by Spring's ResourceLoader that is not unique but can result in =
multiple matching files.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Do 24.06.2004 06:06
An: spr...@li...
Betreff: Re: [Springframework-developer] Retrieve all class path =
resources with the same name



I've been thinking about this, and was wondering if it's appropriate
that _all_ matching resources are found, all the time, and also if we
should be worried about a backwards incompatible change.

Before, in ClassPathXmlApplicationContext, the locations
   beans.xml
and
   classpath:beans.xml
would return one resource, regardless of how many there were.

Now the former still returns one, while the latter returns 1-x.

Is it a problem that we've made a backwards incompatible change for the
latter form?
Is it a problem that somebody, if they want just one resource, has to
know that they need to use the first form? Additionally to this, this
distinction is possible when something like
ClassPathXmlApplicationContext, but for others that override the default
getResourceByPath to default to something else than a classpath
resource,  it's not a possibility.

I guess somebody could say, if there are multiple resources available
under that name, is it ever appropriate to return just one? I think so,
since after all, even in that case, the classloader resource loading
strategy is well defined and deterministic.

Since the 'classpath:' prefix is something we made up, why don't we keep
this for just a single resource, and use something like 'resources:' (or
whatever) to mean multiple resources?

Colin

j=FCrgen h=F6ller [werk3AT] wrote:

>FYI, I've just refined PathMatchingResourcePatternResolver to be able =
to retrieve all class path resources with the same name. It actually =
inherits this from the new base class ClassPathResourcePatternResolver.
>
>http://sourceforge.net/forum/forum.php?thread_id=3D1096825&forum_id=3D25=
0340
>
>So "classpath:/beans.xml" will load all beans.xml files in classes =
directories or JAR files, if passed into =
PathMatchingResourcePatternResolver. Of course, Ant-style file path =
patterns like "/WEB-INF/*-context.xml" still work.
>
>As this is automatically used by "contextConfigLocation" parameters, =
this means that we can specify such a URL for a root web application =
context, for example to auto-load all beans.xml files contained in =
deployed JAR files in WEB-INF\lib (HiveMind-style)!
>
>Juergen
>
>
>DI J=FCrgen H=F6ller
>Senior System Architect
>______________________________________
>
>werk3ATS - division systementwicklung
>werk3AT informations- und mediensysteme
>
>europaplatz 4
>A - 4020 linz
>
>t.  +43 (0) 732 71 65 29 502
>f.  +43 (0) 732 71 65 29 3
>mailto:jue...@we...
>http://www.werk3at.com
>______________________________________
>werk3ATS - WIR ENTWICKELN ERFOLG
>
>




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] OpenSessionInViewFilter ideas

[Norris, T. <tys...@be...>]

Hi Folks -=20
We have been running into problems with migrating an existing CMT EJB
application to use OpenSessionInViewFilter, and here are a couple
thoughts on the subject.

The basic problem is that when a session is created, then a transaction
is initiated and uses that session, if the transaction rolls back, how
can we still access the initial session created in the filter?

Currently the same session is used after entering the transaction. This
is a problem for us using weblogic, since weblogic datasource become
useless after a transaction rolls back (or commits), but I think this is
also general practice for hibernate users to close the session on
rollback:
"If you rollback the transaction you should immediately close and
discard the current session to ensure that Hibernate's internal state is
consistent."

So, what to do? Would it be desirable to build into SessionFactoryUtils
the ability to generate a new session for each new transaction?=20

I have worked around the problem temporarily by "manually" doing this.
That is, I check for an existing JTA transaction, and if its their,
register a new synchronization that holds a reference to the session
opened with the OpenSessionInViewFilter, and the
TransactionSynchronizationManager's session is unbound. When the
transaction completes, TransactionSynchronizationManager session is
re-bound, and non-transactional data access can proceed after the commit
or rollback.

This of course presents a potential problem of loading the same data in
multiple sessions, but this may be negligible for many cases.

Is this something worth adding as an additional parameter to
SessionFactoryUtils.getSession()? When specified (true), if an existing
SessionHolder is found, if not already synchronized with a transaction,
it would be replaced with a new session, then restored after the
transaction completes.

Let me know what you think. Or if there is a better alternative, I'm all
ears :)

Thanks
tyson =20

[Springframework-developer] RE: Not leveraging the CGLIB cache

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

Norris, Tyson wrote:
> (Using the CVS version 1.8 Cglib2ApoProxy) I get everything to work fine
> with the test case I mentioned below even when both proxies are advised,
> unless I remove the equals() method from TestBean.
[snip]
> So, my question is - why should this affect whether CGLIB can cache the
> generated class? I'm back to not understanding if the problem is in
> CGLIB, or Cglib2AopProxy. (or, maybe I'm missing some understanding, and
> the equals method on my beans truly is required...)

The new ProxyCallbackFilter class still uses AopProxyUtils.equalsInProxy in
its equals method. equalsInProxy uses equality of the AdvisedSupport
TargetSource. Depending on the implementation of TargetSource being used, I
think this means it *is* possible for your target bean's equals method to
affect CGLIB caching behavior. I'm not qualified to say whether this is
desirable or not.

Chris

Re: [Springframework-developer] do unit tests fail in CVS HEAD for others?

[Luke T. <ne...@fr...>]

Rod Johnson wrote:

>>Am just doing a fresh checkout and trying again... Do folks 
> 
> run the 
> 
>>tests via Maven or Ant?
> 
> 
> I use Ant, or (usually) run the tests within Eclipse.
> 
> I think the other devs use Ant also. I wouldn't be astounded 
> if the Maven script is out of date.
> 

I try to keep it up to date enough to keep the build running on daily 
basis (usually changed/moved jars are the problem), but keeping track of 
breaks in the tests is trickier.

Luke.


-- 
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk

RE: [Springframework-developer] Re: Not leveraging the CGLIB cache

[Norris, T. <tys...@be...>]

Rob - here's the test case. Notice if you remove the line that makes
target.equals(target2) -> false, the test will pass fine.

Thanks for your help!
Tyson


public void testMultipleProxies() {
    ProxyFactory pf =3D new ProxyFactory(new Class[] { ITestBean.class =
});
            pf.setProxyTargetClass(true);

            MethodInterceptor static1 =3D new TransactionInterceptor();
            pf.addInterceptor(static1);

            TestBean target =3D new TestBean();
            TestBean target2 =3D new TestBean();


            pf.setTarget(target);
            pf.setExposeProxy(false);

            ProxyFactory pf2 =3D new ProxyFactory(new Class[] {
ITestBean.class });
            pf2.copyFrom(pf);

            pf2.addInterceptor(static1);
            pf2.setTarget(target2);

            //if you remove this line, the test will pass...
            target2.setAge(target.getAge()+1);


            ITestBean proxy1 =3D (ITestBean) pf.getProxy();
            ITestBean proxy2 =3D (ITestBean) pf2.getProxy();
            System.out.println(proxy1.getClass().getName());
            System.out.println(proxy2.getClass().getName());

            assertTrue(proxy1.getClass() =3D=3D proxy2.getClass());

	}

-----Original Message-----
From: Rob Harrop [mailto:ro...@ca...]=20
Sent: Thursday, June 24, 2004 1:26 PM
To: spr...@li...
Subject: [Springframework-developer] Re: Not leveraging the CGLIB cache

Tyson,

If you can get me a test that fails I will fix the problem, just need to

know exactly what I am fixing.=20

Rob
Norris, Tyson writes:=20

> Thanks Rob - I need to test some more, but maybe this is a problem
> within the AbstractAutoProxyCreator class (which is what our app is
> using to generate proxied instances)=20
>=20
> I'll see if I modify my test case to accurately reflect the failures
we
> get when using (a) the updated Cglib2AopProxy class and (b) the
> AbstractAutoProxyCreator instances.=20
>=20
>=20
> Maybe it has something to do with this snippet:
> 			for (Iterator it =3D allInterceptors.iterator();
> it.hasNext();) {
> 				Advisor advisor =3D
> this.advisorAdapterRegistry.wrap(it.next());
> 				proxyFactory.addAdvisor(advisor);
> 			}
> =09
> proxyFactory.setTargetSource(getTargetSource(bean, beanName));=20
>=20
> affecting the equality of the advisors?=20
>=20
> I'll check into this theory some more...=20
>=20
> Thanks
> tyson=20
>=20
>=20
> -----Original Message-----
> From: Rob Harrop [mailto:ro...@ca...]=20
> Sent: Thursday, June 24, 2004 6:28 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Not leveraging the CGLIB
cache=20
>=20
> I think I have an at least partial answer on this, thanks to some =20
> englightenment from Chris N. As they I could not see the wood for the

> trees. The problem with the test that Tyson supplied was that the
first=20
>=20
> proxy was advised and the second one was not! The =20
> ProxyFactory.copyFrom() method does not copy advisors. So as Chris =20
> pointed out we need to implement CallbackFilter.equals() to check that

> the CallbackFilters are for the same proxies. What confused me was - I

> knew we had this, Rod had added that some time ago. Then I noticed in

> the debugger that only the first proxy had the advisor, so Cglib was =20
> correctly returning a different proxy class. The rule of thumb is you

> will only get the same proxy class if the superclass and advice set is

> the same.=20
>=20
> I took the opportunity to make a refactor suggested by Chris and I =20
> added a test to verify this case. I plan to improve the =20
> CallbackFilter.hashCode() implementation to increase performance in
the=20
>=20
> next few days.=20
>=20
> Rob=20
>=20
>=20
> On 22 Jun 2004, at 22:35, Norris, Tyson wrote:=20
>=20
>> Thanks for your efforts Rob!=20
>>
>> I suspected something along these lines as well, but also haven't
been
>> able to debug the cglib code enough to figure out why the class is
not
>> cached.=20
>>
>> This did bring to mind a post on cglib-devel list:
>> http://sourceforge.net/mailarchive/forum.php?=20
>> thread_id=3D4141313&forum_id=3D
>> 12922=20
>>
>> a problem with Factory.getCallback() method returning null when there
>> were more than 38 methods. I don't see how this would impact the =20
>> caching
>> of the class, but thought it might be worth a mention based on some
>> complication arising from "too many methods".=20
>>
>> I'll keep digging on this as well.=20
>>
>> Thanks
>> tyson=20
>>
>> -----Original Message-----
>> From: Rob Harrop [mailto:ro...@ca...]
>> Sent: Tuesday, June 22, 2004 1:33 PM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] Not leveraging the CGLIB
> cache
>>
>> Tyson (All),=20
>>
>> Some more news on this. Did some extensive testing on the train today
>> and I am a bit stumped to be honest. The Cglib Key class that is
>> created for both proxies is the same and therefore should use same
>> class as the first instance, and indeed this works when the target is
>> unadvised. I have two theories which I have been unable to test so
far
>> but hope to do so tomorrow/Thurs unless anyone else gets to it first.
>> First theory (the unlikely one), is that the SoftReferences used to
>> cache the proxy is being collected. Second, more likely theory, is
> that
>> the Key class some how fails to work correctly when there are a
> certain
>> number of callbacks. There are a LOT more callbacks created for
> advised
>> targets than non advised targets.=20
>>
>> I will raise this issue with the guys at Cglib, we are already
>> discussing some other matters. But I think that we could also create
>> our own cache as long we get all of the relevant parameters (not just
>> superclass name) in the key for the cache. I will experiment with
this
>> and see where I get.=20
>>
>> Rob
>> On 22 Jun 2004, at 09:21, Rob Harrop wrote:=20
>>
>>> Tyson,=20
>>>
>>> I have managed to narrow this down to occuring only on advised
>>> targets. I anticipate this is a problem with the hashcode
>>> implementation of one of the callbacks and I will hopefully have a
> fix
>>
>>> by the end of the day.=20
>>>
>>> Rob=20
>>>
>>> On 22 Jun 2004, at 01:34, Norris, Tyson wrote:=20
>>>
>>>> public void testMultipleProxies() {
>>>>     ProxyFactory pf =3D new ProxyFactory(new Class[] {
ITestBean.class
>>>> });
>>>>             pf.setProxyTargetClass(true);=20
>>>>
>>>>             MethodInterceptor static1 =3D new NopInterceptor();=20
>>>>
>>>> //            MethodInterceptor static2 =3D new
>>>> Advices.ReadDataInterceptor();=20
>>>>
>>>>             pf.addInterceptor(static1);
>>>> //            pf.addInterceptor(static2);=20
>>>>
>>>> //            Advisor static3 =3D new Advices.SetterPointCut(new
>>>> Advices.NopInterceptor());
>>>> //            Advisor static4 =3D new Advices.SetterPointCut(new
>>>> Advices.ReadDataInterceptor());
>>>> //
>>>> //            pf.addAdvisor(static3);
>>>> //            pf.addAdvisor(static4);=20
>>>>
>>>> //            pf.addAdvisor(new Advices.ObjectReturnPointCut(new
>>>> Advices.NopInterceptor()));=20
>>>>
>>>>             TestBean target =3D new TestBean();
>>>>             TestBean target2 =3D new TestBean();=20
>>>>
>>>>
>>>>             pf.setTarget(target);
>>>>             pf.setFrozen(true);
>>>>             pf.setExposeProxy(false);=20
>>>>
>>>>             ProxyFactory pf2 =3D new ProxyFactory(new Class[] {
>>>> ITestBean.class });
>>>>             pf2.copyFrom(pf);
>>>>             pf2.setTarget(target2);=20
>>>>
>>>>
>>>>             ITestBean proxy1 =3D (ITestBean) pf.getProxy();
>>>>             ITestBean proxy2 =3D (ITestBean) pf2.getProxy();=20
>>>>
>>>>             System.out.println(proxy1.getClass().getName());
>>>>             System.out.println(proxy2.getClass().getName());=20
>>>>
>>>>             assertTrue(proxy1.getClass() =3D=3D proxy2.getClass()); =

>>>>
>>>> 	}
>>>=20
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email sponsored by Black Hat Briefings & Training.
>>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital
>>> self defense, top technical experts, no vendor pitches, unmatched
>>> networking opportunities. Visit www.blackhat.com
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...=20
>>>
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>=20
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by Black Hat Briefings & Training.
>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>> digital self defense, top technical experts, no vendor pitches,
>> unmatched networking opportunities. Visit www.blackhat.com
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>>
https://lists.sourceforge.net/lists/listinfo/springframework-developer=20
>>
>>=20
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by Black Hat Briefings & Training.
>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>> digital self defense, top technical experts, no vendor pitches,
>> unmatched networking opportunities. Visit www.blackhat.com
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>>
https://lists.sourceforge.net/lists/listinfo/springframework-developer=20
>>
> =20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
> digital self defense, top technical experts, no vendor pitches,=20
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

>=20
> =20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
> digital self defense, top technical experts, no vendor pitches,=20
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
=20


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
digital self defense, top technical experts, no vendor pitches,=20
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] spring build.35 Build Successful

[<al...@jt...>]

<html><head>
<style>
.white { color:#FFFFFF }.index { background-color:#FFFFFF }.index-passed { =
color:#004400 }.index-failed { color:#FF0000; font-weight:bold }.index-head=
er { font-weight:bold }.link { font-family:arial,helvetica,sans-serif; font=
-size:10pt; color:#FFFFFF; text-decoration:none; }.tab-table { margin: 0em =
0em 0.5em 0em; }.tabs { font-family:arial,helvetica,sans-serif; font-size:8=
pt; color:#000000; font-weight:bold; padding: 0em 2em; background-color:#EE=
EEEE; }.tabs-link { color:#000000; text-decoration:none; }.tabs-link:visite=
d { color:#000000; text-decoration:none; }.tabs-selected { font-family:aria=
l,helvetica,sans-serif; font-size:8pt; color:#000000; font-weight:bold; pad=
ding: 0em 2em; }.tabs-selected { border: inset; }.header-title { font-famil=
y:arial,helvetica,sans-serif; font-size:12pt; color:#000000; font-weight:bo=
ld; }.header-label { font-weight:bold; }.header-data { font-family:arial,he=
lvetica,sans-serif; font-size:10pt; color:#000000; }.modifications-data { f=
ont-family:arial,helvetica,sans-serif; font-size:8pt; color:#000000; }.modi=
fications-sectionheader { background-color:#000066; font-family:arial,helve=
tica,sans-serif; font-size:10pt; color:#FFFFFF; }.modifications-oddrow { ba=
ckground-color:#CCCCCC }.modifications-evenrow { background-color:#FFFFCC }=
.changelists-oddrow { background-color:#CCCCCC }.changelists-evenrow { back=
ground-color:#FFFFCC }.changelists-file-spacer { background-color:#FFFFFF }=
.changelists-file-evenrow { background-color:#EEEEEE }.changelists-file-odd=
row { background-color:#FFFFEE }.changelists-file-header { background-color=
:#666666; font-family:arial,helvetica,sans-serif; font-size:8pt; color:#FFF=
FFF; }.compile-data { font-family:arial,helvetica,sans-serif; font-size:8pt=
; color:#000000; }.compile-error-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#FF0000; }.compile-warn-data { font-family:arial,=
helvetica,sans-serif; font-size:8pt; color:#CC9900; }.compile-sectionheader=
 { background-color:#000066; font-family:arial,helvetica,sans-serif; font-s=
ize:10pt; color:#FFFFFF; }.distributables-data { font-family:arial,helvetic=
a,sans-serif; font-size:8pt; color:#000000; }.distributables-sectionheader =
{ background-color:#000066; font-family:arial,helvetica,sans-serif; font-si=
ze:10pt; color:#FFFFFF; }.distributables-oddrow { background-color:#CCCCCC =
}.unittests-sectionheader { background-color:#000066; font-family:arial,hel=
vetica,sans-serif; font-size:10pt; color:#FFFFFF; }.unittests-oddrow { back=
ground-color:#CCCCCC }.unittests-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#000000; }.unittests-error { font-family:arial,he=
lvetica,sans-serif; font-size:8pt; color:#FF0000; }.checkstyle-oddrow { bac=
kground-color:#CCCCCC }.checkstyle-data { font-family:arial,helvetica,sans-=
serif; font-size:8pt; color:#000000; }.checkstyle-sectionheader { backgroun=
d-color:#000066; font-family:arial,helvetica,sans-serif; font-size:10pt; co=
lor:#FFFFFF; }
</style>
</head><body>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"header-title">BUILD COMPLETE&nbsp;-&nbsp;     =
               build.35</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build:&nbsp;</span>06/25/2004 00:16:18</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>13 minutes 32 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed:&nbsp;</span>06/24/2004 18:24:11</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try:&nbsp;</span>Added documentation for Hessian, Burlap and RMI</td></tr><=
/table><p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"/><p>
<p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"><tr><td class=
=3D"compile-sectionheader">                        &nbsp;Errors/Warnings: (=
6)                    </td></tr><tr><td><pre class=3D"compile-error-data">N=
ote: Some input files use or override a deprecated API.<br class=3D"none"/>=
Note: Recompile with -deprecation for details.Note: /jteam/build/checkout/s=
pring/spring/mock/org/springframework/mock/web/MockHttpSession.java uses or=
 overrides a deprecated API.<br class=3D"none"/>Note: Recompile with -depre=
cation for details.<br class=3D"none"/>Note: Some input files use or overri=
de a deprecated API.<br class=3D"none"/>Note: Recompile with -deprecation f=
or details.<br class=3D"none"/></pre></td></tr></table><p>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"unittests-sectionheader">       =
            &nbsp;Unit Tests: (1470)                </td></tr><tr><td><tabl=
e width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"c=
enter"><tr><td class=3D"unittests-data">                failure            =
</td><td width=3D"40%" class=3D"unittests-data">testHomePage</td><td width=
=3D"40%" class=3D"unittests-data">org.springframework.apptests.buildtest.Al=
lTests</td></tr></table></td></tr><tr></tr><tr><td colspan=3D"2">&nbsp;</td=
></tr><tr><td colspan=3D"4" class=3D"unittests-sectionheader">             =
       &nbsp;Unit Test Error Details:&nbsp;(1)                </td></tr><tr=
><td class=3D"unittests-data" colspan=3D"2">                Test:&nbsp;test=
HomePage</td></tr><tr><td class=3D"unittests-data" colspan=3D"2">          =
      Class:&nbsp;org.springframework.apptests.buildtest.AllTests</td></tr>=
<tr><td class=3D"unittests-data" colspan=3D"2">                Type: junit.=
framework.AssertionFailedError</td></tr><tr><td class=3D"unittests-data" co=
lspan=3D"2">                Message: Exception while testing URL http://loc=
alhost:13084/buildtest:java.io.IOException</td></tr><tr><td class=3D"unitte=
sts-error" colspan=3D"2"><pre>junit.framework.AssertionFailedError: Excepti=
on while testing URL http://localhost:13084/buildtest:java.io.IOException<b=
r>=09at org.springframework.apptests.buildtest.AllTests.testHomePage(Unknow=
n Source)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Meth=
od)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess=
orImpl.java:39)<br>=09at sun.reflect.DelegatingMethodAccessorImpl.invoke(De=
legatingMethodAccessorImpl.java:25)<br></pre></td></tr><tr><td colspan=3D"2=
">&nbsp;</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"modifications-sectionheader">   =
                 &nbsp;Modifications since last build:&nbsp;               =
     (38)                </td></tr><tr class=3D"modifications-evenrow"><td =
class=3D"modifications-data">modified</td><td class=3D"modifications-data">=
aarendsen</td><td class=3D"modifications-data">docs/reference/src/index.xml=
</td><td class=3D"modifications-data">Added documentation for Hessian, Burl=
ap and RMI</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modific=
ations-data">added</td><td class=3D"modifications-data">aarendsen</td><td c=
lass=3D"modifications-data">docs/reference/src/remoting.xml</td><td class=
=3D"modifications-data">Added documentation for Hessian, Burlap and RMI</td=
></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-data">=
modified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"mod=
ifications-data">/changelog.txt</td><td class=3D"modifications-data">rework=
ed root/child bean definition concept</td></tr><tr class=3D"modifications-o=
ddrow"><td class=3D"modifications-data">modified</td><td class=3D"modificat=
ions-data">jhoeller</td><td class=3D"modifications-data">test/org/springfra=
mework/beans/DerivedTestBean.java</td><td class=3D"modifications-data">rewo=
rked root/child bean definition concept</td></tr><tr class=3D"modifications=
-evenrow"><td class=3D"modifications-data">modified</td><td class=3D"modifi=
cations-data">jhoeller</td><td class=3D"modifications-data">test/org/spring=
framework/beans/TestBean.java</td><td class=3D"modifications-data">reworked=
 root/child bean definition concept</td></tr><tr class=3D"modifications-odd=
row"><td class=3D"modifications-data">modified</td><td class=3D"modificatio=
ns-data">jhoeller</td><td class=3D"modifications-data">test/org/springframe=
work/beans/factory/xml/XmlBeanFactoryTestSuite.java</td><td class=3D"modifi=
cations-data">reworked root/child bean definition concept</td></tr><tr clas=
s=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td><=
td class=3D"modifications-data">jhoeller</td><td class=3D"modifications-dat=
a">test/org/springframework/beans/factory/xml/child.xml</td><td class=3D"mo=
difications-data">reworked root/child bean definition concept</td></tr><tr =
class=3D"modifications-oddrow"><td class=3D"modifications-data">modified</t=
d><td class=3D"modifications-data">jhoeller</td><td class=3D"modifications-=
data">test/org/springframework/beans/factory/xml/parent.xml</td><td class=
=3D"modifications-data">reworked root/child bean definition concept</td></t=
r><tr class=3D"modifications-evenrow"><td class=3D"modifications-data">modi=
fied</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modific=
ations-data">src/org/springframework/beans/factory/support/AbstractAutowire=
CapableBeanFactory.java</td><td class=3D"modifications-data">reworked root/=
child bean definition concept</td></tr><tr class=3D"modifications-oddrow"><=
td class=3D"modifications-data">modified</td><td class=3D"modifications-dat=
a">jhoeller</td><td class=3D"modifications-data">src/org/springframework/be=
ans/factory/support/AbstractBeanDefinition.java</td><td class=3D"modificati=
ons-data">reworked root/child bean definition concept</td></tr><tr class=3D=
"modifications-evenrow"><td class=3D"modifications-data">modified</td><td c=
lass=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">s=
rc/org/springframework/beans/factory/support/AbstractBeanFactory.java</td><=
td class=3D"modifications-data">reworked root/child bean definition concept=
</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-dat=
a">modified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"=
modifications-data">src/org/springframework/beans/factory/support/ChildBean=
Definition.java</td><td class=3D"modifications-data">reworked root/child be=
an definition concept</td></tr><tr class=3D"modifications-evenrow"><td clas=
s=3D"modifications-data">modified</td><td class=3D"modifications-data">jhoe=
ller</td><td class=3D"modifications-data">src/org/springframework/beans/fac=
tory/support/DefaultListableBeanFactory.java</td><td class=3D"modifications=
-data">reworked root/child bean definition concept</td></tr><tr class=3D"mo=
difications-oddrow"><td class=3D"modifications-data">modified</td><td class=
=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">src/o=
rg/springframework/beans/factory/support/MethodOverrides.java</td><td class=
=3D"modifications-data">reworked root/child bean definition concept</td></t=
r><tr class=3D"modifications-evenrow"><td class=3D"modifications-data">modi=
fied</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modific=
ations-data">src/org/springframework/beans/factory/support/RootBeanDefiniti=
on.java</td><td class=3D"modifications-data">reworked root/child bean defin=
ition concept</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modi=
fications-data">modified</td><td class=3D"modifications-data">jhoeller</td>=
<td class=3D"modifications-data">src/org/springframework/beans/factory/xml/=
DefaultXmlBeanDefinitionParser.java</td><td class=3D"modifications-data">re=
worked root/child bean definition concept</td></tr><tr class=3D"modificatio=
ns-evenrow"><td class=3D"modifications-data">modified</td><td class=3D"modi=
fications-data">jhoeller</td><td class=3D"modifications-data">src/org/sprin=
gframework/beans/factory/config/ConstructorArgumentValues.java</td><td clas=
s=3D"modifications-data">reworked root/child bean definition concept</td></=
tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">modi=
fied</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modific=
ations-data">test/org/springframework/aop/framework/AbstractAopProxyTests.j=
ava</td><td class=3D"modifications-data">polishing</td></tr><tr class=3D"mo=
difications-evenrow"><td class=3D"modifications-data">modified</td><td clas=
s=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">test=
/org/springframework/aop/framework/CglibProxyTests.java</td><td class=3D"mo=
difications-data">polishing</td></tr><tr class=3D"modifications-oddrow"><td=
 class=3D"modifications-data">modified</td><td class=3D"modifications-data"=
>jhoeller</td><td class=3D"modifications-data">test/org/springframework/aop=
/framework/JdkDynamicProxyTests.java</td><td class=3D"modifications-data">p=
olishing</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifica=
tions-data">modified</td><td class=3D"modifications-data">jhoeller</td><td =
class=3D"modifications-data">test/org/springframework/aop/framework/Optimiz=
edCglibProxyTests.java</td><td class=3D"modifications-data">polishing</td><=
/tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">mod=
ified</td><td class=3D"modifications-data">colins</td><td class=3D"modifica=
tions-data">/project.properties</td><td class=3D"modifications-data">point =
to current cglib-2.0.2-dev.jar</td></tr><tr class=3D"modifications-evenrow"=
><td class=3D"modifications-data">modified</td><td class=3D"modifications-d=
ata">robharrop</td><td class=3D"modifications-data">test/org/springframewor=
k/aop/framework/CglibProxyTests.java</td><td class=3D"modifications-data">*=
** empty log message ***</td></tr><tr class=3D"modifications-oddrow"><td cl=
ass=3D"modifications-data">modified</td><td class=3D"modifications-data">ro=
bharrop</td><td class=3D"modifications-data">src/org/springframework/aop/fr=
amework/Cglib2AopProxy.java</td><td class=3D"modifications-data">*** empty =
log message ***</td></tr><tr class=3D"modifications-evenrow"><td class=3D"m=
odifications-data">modified</td><td class=3D"modifications-data">jhoeller</=
td><td class=3D"modifications-data">/changelog.txt</td><td class=3D"modific=
ations-data">added support for factory methods and lookup methods</td></tr>=
<tr class=3D"modifications-oddrow"><td class=3D"modifications-data">modifie=
d</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modificati=
ons-data">src/org/springframework/beans/factory/support/AbstractAutowireCap=
ableBeanFactory.java</td><td class=3D"modifications-data">polishing</td></t=
r><tr class=3D"modifications-evenrow"><td class=3D"modifications-data">modi=
fied</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modific=
ations-data">src/org/springframework/beans/factory/support/AbstractBeanDefi=
nition.java</td><td class=3D"modifications-data">polishing</td></tr><tr cla=
ss=3D"modifications-oddrow"><td class=3D"modifications-data">modified</td><=
td class=3D"modifications-data">jhoeller</td><td class=3D"modifications-dat=
a">src/org/springframework/beans/factory/support/InstantiationStrategy.java=
</td><td class=3D"modifications-data">polishing</td></tr><tr class=3D"modif=
ications-evenrow"><td class=3D"modifications-data">modified</td><td class=
=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">src/o=
rg/springframework/beans/factory/support/LookupOverride.java</td><td class=
=3D"modifications-data">polishing</td></tr><tr class=3D"modifications-oddro=
w"><td class=3D"modifications-data">modified</td><td class=3D"modifications=
-data">jhoeller</td><td class=3D"modifications-data">src/org/springframewor=
k/beans/factory/support/MethodOverride.java</td><td class=3D"modifications-=
data">polishing</td></tr><tr class=3D"modifications-evenrow"><td class=3D"m=
odifications-data">modified</td><td class=3D"modifications-data">jhoeller</=
td><td class=3D"modifications-data">src/org/springframework/beans/factory/s=
upport/MethodOverrides.java</td><td class=3D"modifications-data">polishing<=
/td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data=
">modified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"m=
odifications-data">src/org/springframework/beans/factory/support/RootBeanDe=
finition.java</td><td class=3D"modifications-data">polishing</td></tr><tr c=
lass=3D"modifications-evenrow"><td class=3D"modifications-data">modified</t=
d><td class=3D"modifications-data">jhoeller</td><td class=3D"modifications-=
data">test/org/springframework/beans/factory/xml/OverrideOneMethod.java</td=
><td class=3D"modifications-data">polishing</td></tr><tr class=3D"modificat=
ions-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"mod=
ifications-data">jhoeller</td><td class=3D"modifications-data">src/org/spri=
ngframework/beans/factory/support/CglibSubclassingInstantiationStrategy.jav=
a</td><td class=3D"modifications-data">renamed DefaultInstantationStrategy =
to SimpleInstantiationStrategy</td></tr><tr class=3D"modifications-evenrow"=
><td class=3D"modifications-data">deleted</td><td class=3D"modifications-da=
ta">jhoeller</td><td class=3D"modifications-data">src/org/springframework/b=
eans/factory/support/DefaultInstantiationStrategy.java</td><td class=3D"mod=
ifications-data">renamed DefaultInstantationStrategy to SimpleInstantiation=
Strategy</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modificat=
ions-data">added</td><td class=3D"modifications-data">jhoeller</td><td clas=
s=3D"modifications-data">src/org/springframework/beans/factory/support/Simp=
leInstantiationStrategy.java</td><td class=3D"modifications-data">renamed D=
efaultInstantationStrategy to SimpleInstantiationStrategy</td></tr><tr clas=
s=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td><=
td class=3D"modifications-data">johnsonr</td><td class=3D"modifications-dat=
a">src/org/springframework/beans/factory/support/CglibSubclassingInstantiat=
ionStrategy.java</td><td class=3D"modifications-data">Moved log up to Defau=
ltInstantiationStrategy. Corrected typo ("suppored")in exception message</t=
d></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">=
modified</td><td class=3D"modifications-data">johnsonr</td><td class=3D"mod=
ifications-data">src/org/springframework/beans/factory/support/DefaultInsta=
ntiationStrategy.java</td><td class=3D"modifications-data">Moved log up to =
DefaultInstantiationStrategy. Corrected typo ("suppored")in exception messa=
ge</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"distributables-sectionheader">                =
        &nbsp;Deployments by this build:&nbsp;(8)                    </td><=
/tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/checko=
ut/spring/spring/dist/spring.jar</td></tr><tr class=3D"distributables-oddro=
w"><td class=3D"distributables-data">Building war: /jteam/build/checkout/sp=
ring/spring/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr><td c=
lass=3D"distributables-data">Building war: /jteam/build/checkout/spring/spr=
ing/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr class=3D"dist=
ributables-oddrow"><td class=3D"distributables-data">Building war: /jteam/b=
uild/checkout/spring/spring/autobuilds/apps/buildtest/dist/buildtest.war</t=
d></tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/che=
ckout/spring/spring/autobuilds/apps/jpetstore/war/WEB-INF/lib/jpetstore.jar=
</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distributables-d=
ata">Building war: /jteam/build/checkout/spring/spring/autobuilds/apps/jpet=
store/dist/jpetstore.war</td></tr><tr><td class=3D"distributables-data">Bui=
lding jar: /jteam/build/checkout/spring/spring/autobuilds/apps/jpetstore/wa=
r/WEB-INF/lib/jpetstore.jar</td></tr><tr class=3D"distributables-oddrow"><t=
d class=3D"distributables-data">Building war: /jteam/build/checkout/spring/=
spring/autobuilds/apps/jpetstore/dist/jpetstore.war</td></tr></table>
</body></html>

RE: [Springframework-developer] Not leveraging the CGLIB cache

[Norris, T. <tys...@be...>]

OK, more info on this.=20

(Using the CVS version 1.8 Cglib2ApoProxy) I get everything to work fine
with the test case I mentioned below even when both proxies are advised,
unless I remove the equals() method from TestBean.=20

I revised the test case below to use my application context to get the
beans, and it works fine too, as long as equals() method is there and
evaluates to true.

This is why it fails on my beans - since I don't have an equals() method
that evaluates to true. I could add this to my beans, but I'm not sure
why I would have to.

So, my question is - why should this affect whether CGLIB can cache the
generated class? I'm back to not understanding if the problem is in
CGLIB, or Cglib2AopProxy. (or, maybe I'm missing some understanding, and
the equals method on my beans truly is required...)=20

Any thoughts?

Thanks
tyson

-----Original Message-----
From: Norris, Tyson=20
Sent: Thursday, June 24, 2004 11:05 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Not leveraging the CGLIB cache

Thanks Rob - I need to test some more, but maybe this is a problem
within the AbstractAutoProxyCreator class (which is what our app is
using to generate proxied instances)

I'll see if I modify my test case to accurately reflect the failures we
get when using (a) the updated Cglib2AopProxy class and (b) the
AbstractAutoProxyCreator instances.


Maybe it has something to do with this snippet:
			for (Iterator it =3D allInterceptors.iterator();
it.hasNext();) {
				Advisor advisor =3D
this.advisorAdapterRegistry.wrap(it.next());
				proxyFactory.addAdvisor(advisor);
			}
=09
proxyFactory.setTargetSource(getTargetSource(bean, beanName));

affecting the equality of the advisors?

I'll check into this theory some more...

Thanks
tyson


-----Original Message-----
From: Rob Harrop [mailto:ro...@ca...]=20
Sent: Thursday, June 24, 2004 6:28 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Not leveraging the CGLIB cache

I think I have an at least partial answer on this, thanks to some =20
englightenment from Chris N. As they I could not see the wood for the =20
trees. The problem with the test that Tyson supplied was that the first

proxy was advised and the second one was not! The =20
ProxyFactory.copyFrom() method does not copy advisors. So as Chris =20
pointed out we need to implement CallbackFilter.equals() to check that =20
the CallbackFilters are for the same proxies. What confused me was - I =20
knew we had this, Rod had added that some time ago. Then I noticed in =20
the debugger that only the first proxy had the advisor, so Cglib was =20
correctly returning a different proxy class. The rule of thumb is you =20
will only get the same proxy class if the superclass and advice set is =20
the same.

I took the opportunity to make a refactor suggested by Chris and I =20
added a test to verify this case. I plan to improve the =20
CallbackFilter.hashCode() implementation to increase performance in the

next few days.

Rob


On 22 Jun 2004, at 22:35, Norris, Tyson wrote:

> Thanks for your efforts Rob!
>
> I suspected something along these lines as well, but also haven't been
> able to debug the cglib code enough to figure out why the class is not
> cached.
>
> This did bring to mind a post on cglib-devel list:
> http://sourceforge.net/mailarchive/forum.php?=20
> thread_id=3D4141313&forum_id=3D
> 12922
>
> a problem with Factory.getCallback() method returning null when there
> were more than 38 methods. I don't see how this would impact the =20
> caching
> of the class, but thought it might be worth a mention based on some
> complication arising from "too many methods".
>
> I'll keep digging on this as well.
>
> Thanks
> tyson
>
> -----Original Message-----
> From: Rob Harrop [mailto:ro...@ca...]
> Sent: Tuesday, June 22, 2004 1:33 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Not leveraging the CGLIB
cache
>
> Tyson (All),
>
> Some more news on this. Did some extensive testing on the train today
> and I am a bit stumped to be honest. The Cglib Key class that is
> created for both proxies is the same and therefore should use same
> class as the first instance, and indeed this works when the target is
> unadvised. I have two theories which I have been unable to test so far
> but hope to do so tomorrow/Thurs unless anyone else gets to it first.
> First theory (the unlikely one), is that the SoftReferences used to
> cache the proxy is being collected. Second, more likely theory, is
that
> the Key class some how fails to work correctly when there are a
certain
> number of callbacks. There are a LOT more callbacks created for
advised
> targets than non advised targets.
>
> I will raise this issue with the guys at Cglib, we are already
> discussing some other matters. But I think that we could also create
> our own cache as long we get all of the relevant parameters (not just
> superclass name) in the key for the cache. I will experiment with this
> and see where I get.
>
> Rob
> On 22 Jun 2004, at 09:21, Rob Harrop wrote:
>
>> Tyson,
>>
>> I have managed to narrow this down to occuring only on advised
>> targets. I anticipate this is a problem with the hashcode
>> implementation of one of the callbacks and I will hopefully have a
fix
>
>> by the end of the day.
>>
>> Rob
>>
>> On 22 Jun 2004, at 01:34, Norris, Tyson wrote:
>>
>>> public void testMultipleProxies() {
>>>     ProxyFactory pf =3D new ProxyFactory(new Class[] { =
ITestBean.class
>>> });
>>>             pf.setProxyTargetClass(true);
>>>
>>>             MethodInterceptor static1 =3D new NopInterceptor();
>>>
>>> //            MethodInterceptor static2 =3D new
>>> Advices.ReadDataInterceptor();
>>>
>>>             pf.addInterceptor(static1);
>>> //            pf.addInterceptor(static2);
>>>
>>> //            Advisor static3 =3D new Advices.SetterPointCut(new
>>> Advices.NopInterceptor());
>>> //            Advisor static4 =3D new Advices.SetterPointCut(new
>>> Advices.ReadDataInterceptor());
>>> //
>>> //            pf.addAdvisor(static3);
>>> //            pf.addAdvisor(static4);
>>>
>>> //            pf.addAdvisor(new Advices.ObjectReturnPointCut(new
>>> Advices.NopInterceptor()));
>>>
>>>             TestBean target =3D new TestBean();
>>>             TestBean target2 =3D new TestBean();
>>>
>>>
>>>             pf.setTarget(target);
>>>             pf.setFrozen(true);
>>>             pf.setExposeProxy(false);
>>>
>>>             ProxyFactory pf2 =3D new ProxyFactory(new Class[] {
>>> ITestBean.class });
>>>             pf2.copyFrom(pf);
>>>             pf2.setTarget(target2);
>>>
>>>
>>>             ITestBean proxy1 =3D (ITestBean) pf.getProxy();
>>>             ITestBean proxy2 =3D (ITestBean) pf2.getProxy();
>>>
>>>             System.out.println(proxy1.getClass().getName());
>>>             System.out.println(proxy2.getClass().getName());
>>>
>>>             assertTrue(proxy1.getClass() =3D=3D proxy2.getClass());
>>>
>>> 	}
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by Black Hat Briefings & Training.
>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital
>> self defense, top technical experts, no vendor pitches, unmatched
>> networking opportunities. Visit www.blackhat.com
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
digital self defense, top technical experts, no vendor pitches,=20
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
digital self defense, top technical experts, no vendor pitches,=20
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: Not leveraging the CGLIB cache

[Rob H. <ro...@ca...>]

Tyson,

If you can get me a test that fails I will fix the problem, just need to 
know exactly what I am fixing. 

Rob
Norris, Tyson writes: 

> Thanks Rob - I need to test some more, but maybe this is a problem
> within the AbstractAutoProxyCreator class (which is what our app is
> using to generate proxied instances) 
> 
> I'll see if I modify my test case to accurately reflect the failures we
> get when using (a) the updated Cglib2AopProxy class and (b) the
> AbstractAutoProxyCreator instances. 
> 
> 
> Maybe it has something to do with this snippet:
> 			for (Iterator it = allInterceptors.iterator();
> it.hasNext();) {
> 				Advisor advisor =
> this.advisorAdapterRegistry.wrap(it.next());
> 				proxyFactory.addAdvisor(advisor);
> 			}
> 	
> proxyFactory.setTargetSource(getTargetSource(bean, beanName)); 
> 
> affecting the equality of the advisors? 
> 
> I'll check into this theory some more... 
> 
> Thanks
> tyson 
> 
> 
> -----Original Message-----
> From: Rob Harrop [mailto:ro...@ca...] 
> Sent: Thursday, June 24, 2004 6:28 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Not leveraging the CGLIB cache 
> 
> I think I have an at least partial answer on this, thanks to some  
> englightenment from Chris N. As they I could not see the wood for the  
> trees. The problem with the test that Tyson supplied was that the first 
> 
> proxy was advised and the second one was not! The  
> ProxyFactory.copyFrom() method does not copy advisors. So as Chris  
> pointed out we need to implement CallbackFilter.equals() to check that  
> the CallbackFilters are for the same proxies. What confused me was - I  
> knew we had this, Rod had added that some time ago. Then I noticed in  
> the debugger that only the first proxy had the advisor, so Cglib was  
> correctly returning a different proxy class. The rule of thumb is you  
> will only get the same proxy class if the superclass and advice set is  
> the same. 
> 
> I took the opportunity to make a refactor suggested by Chris and I  
> added a test to verify this case. I plan to improve the  
> CallbackFilter.hashCode() implementation to increase performance in the 
> 
> next few days. 
> 
> Rob 
> 
> 
> On 22 Jun 2004, at 22:35, Norris, Tyson wrote: 
> 
>> Thanks for your efforts Rob! 
>>
>> I suspected something along these lines as well, but also haven't been
>> able to debug the cglib code enough to figure out why the class is not
>> cached. 
>>
>> This did bring to mind a post on cglib-devel list:
>> http://sourceforge.net/mailarchive/forum.php? 
>> thread_id=4141313&forum_id=
>> 12922 
>>
>> a problem with Factory.getCallback() method returning null when there
>> were more than 38 methods. I don't see how this would impact the  
>> caching
>> of the class, but thought it might be worth a mention based on some
>> complication arising from "too many methods". 
>>
>> I'll keep digging on this as well. 
>>
>> Thanks
>> tyson 
>>
>> -----Original Message-----
>> From: Rob Harrop [mailto:ro...@ca...]
>> Sent: Tuesday, June 22, 2004 1:33 PM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] Not leveraging the CGLIB
> cache
>>
>> Tyson (All), 
>>
>> Some more news on this. Did some extensive testing on the train today
>> and I am a bit stumped to be honest. The Cglib Key class that is
>> created for both proxies is the same and therefore should use same
>> class as the first instance, and indeed this works when the target is
>> unadvised. I have two theories which I have been unable to test so far
>> but hope to do so tomorrow/Thurs unless anyone else gets to it first.
>> First theory (the unlikely one), is that the SoftReferences used to
>> cache the proxy is being collected. Second, more likely theory, is
> that
>> the Key class some how fails to work correctly when there are a
> certain
>> number of callbacks. There are a LOT more callbacks created for
> advised
>> targets than non advised targets. 
>>
>> I will raise this issue with the guys at Cglib, we are already
>> discussing some other matters. But I think that we could also create
>> our own cache as long we get all of the relevant parameters (not just
>> superclass name) in the key for the cache. I will experiment with this
>> and see where I get. 
>>
>> Rob
>> On 22 Jun 2004, at 09:21, Rob Harrop wrote: 
>>
>>> Tyson, 
>>>
>>> I have managed to narrow this down to occuring only on advised
>>> targets. I anticipate this is a problem with the hashcode
>>> implementation of one of the callbacks and I will hopefully have a
> fix
>>
>>> by the end of the day. 
>>>
>>> Rob 
>>>
>>> On 22 Jun 2004, at 01:34, Norris, Tyson wrote: 
>>>
>>>> public void testMultipleProxies() {
>>>>     ProxyFactory pf = new ProxyFactory(new Class[] { ITestBean.class
>>>> });
>>>>             pf.setProxyTargetClass(true); 
>>>>
>>>>             MethodInterceptor static1 = new NopInterceptor(); 
>>>>
>>>> //            MethodInterceptor static2 = new
>>>> Advices.ReadDataInterceptor(); 
>>>>
>>>>             pf.addInterceptor(static1);
>>>> //            pf.addInterceptor(static2); 
>>>>
>>>> //            Advisor static3 = new Advices.SetterPointCut(new
>>>> Advices.NopInterceptor());
>>>> //            Advisor static4 = new Advices.SetterPointCut(new
>>>> Advices.ReadDataInterceptor());
>>>> //
>>>> //            pf.addAdvisor(static3);
>>>> //            pf.addAdvisor(static4); 
>>>>
>>>> //            pf.addAdvisor(new Advices.ObjectReturnPointCut(new
>>>> Advices.NopInterceptor())); 
>>>>
>>>>             TestBean target = new TestBean();
>>>>             TestBean target2 = new TestBean(); 
>>>>
>>>>
>>>>             pf.setTarget(target);
>>>>             pf.setFrozen(true);
>>>>             pf.setExposeProxy(false); 
>>>>
>>>>             ProxyFactory pf2 = new ProxyFactory(new Class[] {
>>>> ITestBean.class });
>>>>             pf2.copyFrom(pf);
>>>>             pf2.setTarget(target2); 
>>>>
>>>>
>>>>             ITestBean proxy1 = (ITestBean) pf.getProxy();
>>>>             ITestBean proxy2 = (ITestBean) pf2.getProxy(); 
>>>>
>>>>             System.out.println(proxy1.getClass().getName());
>>>>             System.out.println(proxy2.getClass().getName()); 
>>>>
>>>>             assertTrue(proxy1.getClass() == proxy2.getClass()); 
>>>>
>>>> 	}
>>> 
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email sponsored by Black Hat Briefings & Training.
>>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital
>>> self defense, top technical experts, no vendor pitches, unmatched
>>> networking opportunities. Visit www.blackhat.com
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li... 
>>>
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>> 
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by Black Hat Briefings & Training.
>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>> digital self defense, top technical experts, no vendor pitches,
>> unmatched networking opportunities. Visit www.blackhat.com
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer 
>>
>> 
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by Black Hat Briefings & Training.
>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>> digital self defense, top technical experts, no vendor pitches,
>> unmatched networking opportunities. Visit www.blackhat.com
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer 
>>
>  
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer 
> 
>  
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
 

Re: [Springframework-developer] Proposal for Handler/Interceptor Enhancement

[Tim C. <tc...@ta...>]

I recently had a discussion about this with a friend as I ran into the 
same exact need.
I think the idea of having a separate Interceptor mapping would be a 
good idea but at the same time it would mean alot more duplication.
 From what it sounds like it would be similar to using a 
PropertiesMethodNameResolver.
 From the PetClinic example you see:

    <!--
      - This bean is a MethodNameResolver definition for a 
MultiActionController.
      - It maps URLs to methods for the "clinicController" bean.
      -->
    <bean id="clinicControllerResolver" 
class="org.springframework.web.servlet.mvc.multiaction.PropertiesMethodNameResolver">
        <property name="mappings">
        <props>
            <prop key="/welcome.htm">welcomeHandler</prop>
            <prop key="/vets.htm">vetsHandler</prop>
            <prop key="/owner.htm">ownerHandler</prop>
        </props>
        </property>
    </bean>

But yet those same urls are now duplicated in the UrlHandlerMapping:

    <!--
     - This bean is an explicit URL mapper that is used by the 
"petclinic" DispatcherServlet
     - It is used instead of the default BeanNameUrlHandlerMapping.
     -->
    <bean id="urlMapping" 
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
        <property name="mappings">
            <props>
                <prop key="/welcome.htm">clinicController</prop>
                <prop key="/vets.htm">clinicController</prop>
                <prop key="/owner.htm">clinicController</prop>
                <prop key="/findOwners.htm">findOwnersForm</prop>
                <prop key="/editOwner.htm">editOwnerForm</prop>
                <prop key="/addOwner.htm">addOwnerForm</prop>
                <prop key="/addVisit.htm">addVisitForm</prop>
                <prop key="/addPet.htm">addPetForm</prop>
                <prop key="/editPet.htm">editPetForm</prop>
            </props>
        </property>
    </bean>

In the example of a complex application that might have many 
URLs/Interceptor combinations you are not really going to make things 
any less complicated as you will end up having a huge amout of these. I 
wonder if an alternative approach would be to be able to attach 
interceptors directly to controllers:

    <bean id="clinicControllerResolver" 
class="org.springframework.web.servlet.mvc.multiaction.PropertiesMethodNameResolver">
        <property name="interceptors">
            <list>
                <ref bean="signonInterceptor"/>
            </list>
        </property>
        <property name="mappings">
        <props>
            <prop key="/welcome.htm">welcomeHandler</prop>
            <prop key="/vets.htm">vetsHandler</prop>
            <prop key="/owner.htm">ownerHandler</prop>
        </props>
        </property>
    </bean>

    In this way it would be very similar to the SpringAOP concept and 
removes having to find/replace all on a changed/removed URL.
It is also very easy for a maintainer to then come in and see.. oh this 
Controller has to pass thru these interceptors.

-Tim

Rod Johnson wrote:

>>The more I think about this, the more I think it will be useful.  For
>>instance, I'd like to have the OpenSessionInViewInterceptor to apply to
>>everything (/*) where other Interceptors apply to certain Controllers.
>>I'm starting to get a proliferation of UrlHandlerMapping objects just to
>>map different combinations of Interceptors.
>>
>>Jurgen, any more thoughts on this?  I might even implement this one soon
>>because it will greatly simplify things.
>>    
>>
>
>I think the proposal sounds good. I think the point about 2 types of
>interceptors is valid.
>
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
>digital self defense, top technical experts, no vendor pitches, 
>unmatched networking opportunities. Visit www.blackhat.com
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>  
>