springframework-developer — Spring Framework developers list

[Springframework-developer] reloading/hot swapping of beans

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

This is only of use in certain scenarios, but we should maybe examine 
the possibilities w/regards to unloading and reloading of beans. Both 
HiveMind and now Pico
  http://www.picocontainer.org/hotswapping.html
allow reloading of a bean/component returned from the container, due to 
the fact they they automatically introduce a dynamic proxy for the 
object returned form the container.

This has a slight performance impact, but is probably the easiest way to 
handle reloading. Now how much additional 
complexity/variability/breakage this could introduce is I think pretty 
hard to figure out, given the amount of stuff you can do now with things 
like the BeanPostProcessor which can affect the lifecycle of a bunch of 
things in the container.

[Springframework-developer] Re: Is it worth keeping BCEL around a t all?

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

Colin Sampaleanu wrote:
> I can actually answer that, to the extent that looking at the existing
> code in BcelAttributes and BcelAttributeWriter, I don't see anything at
> all in there that you couldn't do with Javassist.

I like the idea of Javassist but in practice it seems to result in messy
StringBuffer code to build up the Java pseudocode. At some point dealing
with the raw bytecodes almost seems easier (but maybe I have been looking
at bytecode for too long :-)
 
> As to this is in any way preferable to using an ASM/cglib combination,
> that's harder to answer. Javassist would probably be a more direct
> replacement on a line by line basis, since it's fundamental approach is
> fairly similar; you work with objects representing the bytecode
> elements. It definitely runs faster than BCEL, and uses less memory, but
> my feeling is that for raw speed and memory usage, ASM's 'visitor'
> approach would win out.

ASM will always win out unless you need to keep a lot of state while
visiting (for things such as code flow analysis), and maybe even then. For
your application of just reading and writing an attribute it is definitely
the way to go.

In CGLIB2 we also have some Ant tasks which should make porting easier. If I
have some spare time I may port the BCEL stuff as an example.

FYI Hibernate 2.1 will use CGLIB2 which means Spring will need to upgrade at
the same time. I can supply you with a patch when you want to do this.

Chris

[Springframework-developer] Re: AOP API - How to keep a ProxyConfig honest ?

[roger h. <apo...@sn...>]

Rod

"Rod Johnson" <rod...@in...> wrote in message
news:30b801c3ac86$99bf92d0$3800a8c0@chopin...
> Roger,
>
> > The ProxyConfig interface allows for the adding / removing of
Interceptors
> &
> > Advice - but nothing to support the changing of the Interfaces being
> > proxied.  At first I thought this was a lack, but then I realised that
> since
> > any interface is logically associated with an interceptor that will
handle
> > the calls on it, this is entirely reasonable.  The only problem at
> present,
> > is the way that ProxyConfigSupport deals with the interfaces - basically
> > they are not all attributable to their respective interceptors - so if
> > someone happens to remove, or change the ProxyInterceptor, we're out of
> > luck.
>
> I think your suggestion has merit, although I think it's unlikely to make
> M3. I don't think it has to break APIs, so I think we could possibly add
an
> Advice (Advisor) such as you describe below subsequently.
>
> > After more pondering it seems to me that one solution would be to add a
> > further Advice - ie one that does for invoking interceptors, what
> > IntroductionAdvice does for IntroductionInterceptors.  For arguments
sake
> > I'll call it an InvokingAdvice, eg:
>
> This does make sense. Adding a ProxyInterceptor could be a shorthand, just
> like adding an Interceptor is a shorthand for adding an Advisor that
matches
> all method invocations.
>
> I have some questions about the interface below, although I think the
> concept is good:

As much as anything, I chose the interface as the quickest way to
illustrate the concept.  I was not, and still am not, clear in my own mind
about what it actually needs to be.  I'll try to answer your questions &
outline further thoughts below...

>
> > public interface InvokingAdvice extends Advice {
> >
> >  ClassFilter getClassFilter();
> >
> >  Interceptor getInterceptor();
> >
> >  Class[] getInterfaces();
> >
> > }
>
> Why would an interceptor be needed at all? The call to proceed() is
> potentially misleading? What about just having a target object or an
> implementation of an invoke(Method, args) method?

In the general case, ie outside of intercepted around advice, there is
clearly no need for an interceptor.

Not sure about your reference to proceed().  Within the current code, where
all advice is actually implemented as intercepted around advice, the one
thing that distinguishes Introduction interceptors and Invoking
interceptors, is that they break the interception call chain, ie. within
MethodInterceptor.invoke(), they return the result of

    invocation.getMethod.invoke()

rather than, as the straight Method interceptors do, returning the result
from the next interceptor, ie

    invocation.proceed()

In other words, the one thing that Introduction and Invoking interceptors do
'not' do, is call proceed().

> What does ClassFilter do here?

Not sure how useful this might be - in the abstract it would enable an
InvokingAdvice to declare the notion that these interfaces can be used to
filter calls on any classes that match this ClassFilter.  I guess that when
building the interceptor chains, there would need to be a check that the
target classes did actually implement the named interfaces, possibly
throwing a config exception if not.

> This could also possibly be another way to do introductions.

Possibly - I guess the difference that's implied in what I've described
above, is that Introductions define a set of 'additional' new interfaces to
be added to any matching classes, whereas Invokers would define a set of
'restricted' interfaces that may be exposed, but that are expected to be
already present on any matching classes.

Perhaps it's useful to recast some of this using the more recent
Interception and Advisor nomenclature, since this helps to eliminate stray
references to interceptors ;)

For the sake of discussion, how about the following:

public interface InvokingAdvisor extends Advisor {

    ClassFilter getClassFilter();

    Class[] getInterfaces();

}

public interface InterceptionInvokingAdvisor extends
                          InterceptionAdvisor, InvokingAdvisor {

    Interceptor getInterceptor()

}

Most of these Invoking interceptors will typically implement
ProxyInterceptor, so maybe this method should be:

    ProxyInterceptor getProxyInterceptor()

I guess the key question is whether its possible to conceive of one that
wouldn't ?

Within the current code base, the non-conformists include:

RmiClientInterceptor
BurlapClientInterceptor
HessianClientInterceptor
LocalSlsbInvokerInterceptor
SimpleRemoteSlsbInvokerInterceptor

In practice, each of these does actually construct a target and thereby
implicitly implement ProxyInterceptor - although the
SlsbInvokerInterceptors, don't construct their target session bean instances
until their invoke() methods are called.  In itself, this is not a problem,
as long as the enclosing StatelessSessionProxyFactoryBeans remember to
create an InvokingAdvice that explicitly declares the business interface.

And for Introductions:

public interface IntroductionAdvisor extends Advisor {

    ClassFilter getClassFilter();

    Class[] getInterfaces();

}

public interface InterceptionIntroductionAdvisor extends
                          InterceptionAdvisor,
                          IntroductionAdvisor {

    IntroductionInterceptor getIntroductionInterceptor();

}

That's about all I can think of for the moment.

Does this help ?

Roger


>
> > With the use of an InvokingAdvice, it becomes possible to require that
all
> > Interfaces passed into ProxyConfigSupport are duly packaged in an
> > appropriate Advice / Interceptor pair.  The only problem, is that lots
of
> > existing code expects to be able to pass in just an
InvokerInterceptor...
>
> But that should still work as a shorthand perhaps.
>
> > In the case of Introductions, the present strategy for dealing with
> > Interceptors that are received by ProxyConfigSupport without an
enclosing
> > Advice, is just to throw a config exception.  However, I think there is

> > actually sufficient information available to be able to build an
enclosing
> > Advice dynamically - ie. the call to ProxyConfigSupport.setInterfaces()
> has
> > supplied a set of candidates interfaces, and the IntroductionInterceptor
> > provides an implementsInterface() call that can be used to test these
for
> > eligibility.
> Fair point.
>
> >
> > The same stretegy can also be employed for InvokerInterceptors, since
each
> > comes together with its target that can be used to test for eligibility.
> > This would leave outstanding. only those interceptors that neither
> implement
> > IntroductionInterceptor nor ProxyInterceptor - for these cases, calls to
> > ProxyFactory.addInterceptor() would still need to be changed to
> > ProxyFactory.addAdvice().   (By inspection, I think these cases include
> code
> > in about 4 core classes and their corresponding test cases)
>
> Regards,
> Rod
>
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

RE: [Springframework-developer] Is it worth keeping BCEL around a t all?

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

Colin,

Thanks for your answer.

Dmitriy.

-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...]=20
Sent: Monday, November 17, 2003 1:38 PM
To: spr...@li...
Cc: 'mpo...@sp...'
Subject: Re: [Springframework-developer] Is it worth keeping BCEL =
around a t
all?


I can actually answer that, to the extent that looking at the existing=20
code in BcelAttributes and BcelAttributeWriter, I don't see anything at =

all in there that you couldn't do with Javassist.

As to this is in any way preferable to using an ASM/cglib combination,=20
that's harder to answer. Javassist would probably be a more direct=20
replacement on a line by line basis, since it's fundamental approach is =

fairly similar; you work with objects representing the bytecode=20
elements. It definitely runs faster than BCEL, and uses less memory, =
but=20
my feeling is that for raw speed and memory usage, ASM's 'visitor'=20
approach would win out.



Kopylenko, Dmitry wrote:

>Mark,
>
>Would it be feasible to create another Attributes impl such as=20
>JavassistAttributes ?
>
>Dmitriy.
>
>-----Original Message-----
>From: Colin Sampaleanu [mailto:col...@ex...]
>Sent: Monday, November 17, 2003 9:26 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Is it worth keeping BCEL =
around a
t
>all?
>
>
>We use Javassist at work in an internal project. I think it's great. I
>don't know how it compares in speed to the using cglib on top of ASM=20
>though; we picked Javassist for this applicaiton mainly because it=20
>allows you to write in real Java code which gets parsed and inserted =
at=20
>runtime...
>
>
>
>
>Kopylenko, Dmitry wrote:
>
> =20
>
>>Has anyone had any experience wit Javassist? Any thoughts/comments?
>>
>>Regards,
>>Dmitriy.
>>
>>-----Original Message-----
>>From: j=FCrgen h=F6ller [werk3AT] =
[mailto:jue...@we...]
>>Sent: Sunday, November 16, 2003 3:59 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Is it worth keeping BCEL=20
>>around at all?
>>
>>
>>+1 - the Hibernate guys typically know what they're doing, so I trust =

>>+them when they switched to ASM :-)
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag
>>von Alef Arendsen (JTeam)
>>Gesendet: So 16.11.2003 19:17
>>An: spr...@li...
>>Betreff: RE: [Springframework-developer] Is it worth keeping BCEL=20
>>around at all?
>>
>>
>>
>>+1
>>
>>Just get rid of if, What Mark is saying about the side file approach
>>indeed sounds like the best approach...
>>
>>Alef
>>
>>
>>=20
>>
>>   =20
>>
>>>Hi,
>>>
>>>I vote to get rid of BCEL as well.  It always seemed large to me. =20
>>>The ASM api indicates it supports attribute manipulation in the=20
>>>bytecode so I
>>>should be able to port the bcel package to asm.   This
>>>feature bytecode
>>>libraries might not be that important anyway since the default=20
>>>storage
>>>mechanism for attributes will likely switch to side files instead of =

>>>putting it in the bytecode.
>>>
>>>Mark
>>>     =20
>>>




-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from =
any
Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=3Dmm/g22lp.tm=
pl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Is it worth keeping BCEL around a t all?

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

I can actually answer that, to the extent that looking at the existing 
code in BcelAttributes and BcelAttributeWriter, I don't see anything at 
all in there that you couldn't do with Javassist.

As to this is in any way preferable to using an ASM/cglib combination, 
that's harder to answer. Javassist would probably be a more direct 
replacement on a line by line basis, since it's fundamental approach is 
fairly similar; you work with objects representing the bytecode 
elements. It definitely runs faster than BCEL, and uses less memory, but 
my feeling is that for raw speed and memory usage, ASM's 'visitor' 
approach would win out.



Kopylenko, Dmitry wrote:

>Mark,
>
>Would it be feasible to create another Attributes impl such as
>JavassistAttributes ?
>
>Dmitriy.
>
>-----Original Message-----
>From: Colin Sampaleanu [mailto:col...@ex...] 
>Sent: Monday, November 17, 2003 9:26 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Is it worth keeping BCEL around a t
>all?
>
>
>We use Javassist at work in an internal project. I think it's great. I 
>don't know how it compares in speed to the using cglib on top of ASM 
>though; we picked Javassist for this applicaiton mainly because it 
>allows you to write in real Java code which gets parsed and inserted at 
>runtime...
>
>
>
>
>Kopylenko, Dmitry wrote:
>
>  
>
>>Has anyone had any experience wit Javassist? Any thoughts/comments?
>>
>>Regards,
>>Dmitriy.
>>
>>-----Original Message-----
>>From: jürgen höller [werk3AT] [mailto:jue...@we...]
>>Sent: Sunday, November 16, 2003 3:59 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Is it worth keeping BCEL around at
>>all?
>>
>>
>>+1 - the Hibernate guys typically know what they're doing, so I trust
>>+them when they switched to ASM :-)
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag 
>>von Alef Arendsen (JTeam)
>>Gesendet: So 16.11.2003 19:17
>>An: spr...@li...
>>Betreff: RE: [Springframework-developer] Is it worth keeping BCEL 
>>around at all?
>>
>>
>>
>>+1
>>
>>Just get rid of if, What Mark is saying about the side file approach 
>>indeed sounds like the best approach...
>>
>>Alef
>>
>>
>> 
>>
>>    
>>
>>>Hi,
>>>
>>>I vote to get rid of BCEL as well.  It always seemed large to me.  The
>>>ASM api indicates it supports attribute manipulation in the bytecode 
>>>so I
>>>should be able to port the bcel package to asm.   This
>>>feature bytecode
>>>libraries might not be that important anyway since the default storage 
>>>mechanism for attributes will likely switch to side files instead of 
>>>putting it in the bytecode.
>>>
>>>Mark
>>>      
>>>

RE: [Springframework-developer] Is it worth keeping BCEL around a t all?

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

Mark,

Would it be feasible to create another Attributes impl such as
JavassistAttributes ?

Dmitriy.

-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...]=20
Sent: Monday, November 17, 2003 9:26 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Is it worth keeping BCEL =
around a t
all?


We use Javassist at work in an internal project. I think it's great. I=20
don't know how it compares in speed to the using cglib on top of ASM=20
though; we picked Javassist for this applicaiton mainly because it=20
allows you to write in real Java code which gets parsed and inserted at =

runtime...




Kopylenko, Dmitry wrote:

>Has anyone had any experience wit Javassist? Any thoughts/comments?
>
>Regards,
>Dmitriy.
>
>-----Original Message-----
>From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
>Sent: Sunday, November 16, 2003 3:59 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Is it worth keeping BCEL =
around at
>all?
>
>
>+1 - the Hibernate guys typically know what they're doing, so I trust
>+them when they switched to ASM :-)
>
>________________________________
>
>Von: spr...@li... im Auftrag=20
>von Alef Arendsen (JTeam)
>Gesendet: So 16.11.2003 19:17
>An: spr...@li...
>Betreff: RE: [Springframework-developer] Is it worth keeping BCEL=20
>around at all?
>
>
>
>+1
>
>Just get rid of if, What Mark is saying about the side file approach=20
>indeed sounds like the best approach...
>
>Alef
>
>
> =20
>
>>Hi,
>>
>>I vote to get rid of BCEL as well.  It always seemed large to me.  =
The
>>ASM api indicates it supports attribute manipulation in the bytecode=20
>>so I
>>should be able to port the bcel package to asm.   This
>>feature bytecode
>>libraries might not be that important anyway since the default =
storage=20
>>mechanism for attributes will likely switch to side files instead of=20
>>putting it in the bytecode.
>>
>>Mark
>>   =20
>>
>
>
>
>-------------------------------------------------------
>This SF. Net email is sponsored by: GoToMyPC
>GoToMyPC is the fast, easy and secure way to access your computer from =

>any Web browser or wireless device. Click here to Try it Free!=20
>https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=3Dmm/g22lp.t=
mp
>l
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>-------------------------------------------------------
>This SF. Net email is sponsored by: GoToMyPC
>GoToMyPC is the fast, easy and secure way to access your computer from =

>any Web browser or wireless device. Click here to Try it Free!=20
>https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=3Dmm/g22lp.t=
mp
>l
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>-------------------------------------------------------
>This SF. Net email is sponsored by: GoToMyPC
>GoToMyPC is the fast, easy and secure way to access your computer from =

>any Web browser or wireless device. Click here to Try it Free!=20
>https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=3D/g22lp.tmp=
l
>_______________________________________________
>Springframework-developer mailing list=20
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> =20
>




-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from =
any
Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=3Dmm/g22lp.tm=
pl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Is it worth keeping BCEL around a t all?

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

We use Javassist at work in an internal project. I think it's great. I 
don't know how it compares in speed to the using cglib on top of ASM 
though; we picked Javassist for this applicaiton mainly because it 
allows you to write in real Java code which gets parsed and inserted at 
runtime...




Kopylenko, Dmitry wrote:

>Has anyone had any experience wit Javassist? Any thoughts/comments?
>
>Regards,
>Dmitriy.
>
>-----Original Message-----
>From: jürgen höller [werk3AT] [mailto:jue...@we...] 
>Sent: Sunday, November 16, 2003 3:59 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Is it worth keeping BCEL around at
>all?
>
>
>+1 - the Hibernate guys typically know what they're doing, so I trust 
>+them when they switched to ASM :-)
>
>________________________________
>
>Von: spr...@li... im Auftrag von
>Alef Arendsen (JTeam)
>Gesendet: So 16.11.2003 19:17
>An: spr...@li...
>Betreff: RE: [Springframework-developer] Is it worth keeping BCEL around at
>all?
>
>
>
>+1
>
>Just get rid of if, What Mark is saying about the side file approach indeed
>sounds like the best approach...
>
>Alef
>
>
>  
>
>>Hi,
>>
>>I vote to get rid of BCEL as well.  It always seemed large to me.  The 
>>ASM api indicates it supports attribute manipulation in the bytecode 
>>so I
>>should be able to port the bcel package to asm.   This
>>feature bytecode
>>libraries might not be that important anyway since the default storage 
>>mechanism for attributes will likely switch to side files instead of 
>>putting it in the bytecode.
>>
>>Mark
>>    
>>
>
>
>
>-------------------------------------------------------
>This SF. Net email is sponsored by: GoToMyPC
>GoToMyPC is the fast, easy and secure way to access your computer from any
>Web browser or wireless device. Click here to Try it Free!
>https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>-------------------------------------------------------
>This SF. Net email is sponsored by: GoToMyPC
>GoToMyPC is the fast, easy and secure way to access your computer from any
>Web browser or wireless device. Click here to Try it Free!
>https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>-------------------------------------------------------
>This SF. Net email is sponsored by: GoToMyPC
>GoToMyPC is the fast, easy and secure way to access your computer from
>any Web browser or wireless device. Click here to Try it Free!
>https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=/g22lp.tmpl
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

RE: [Springframework-developer] Is it worth keeping BCEL around a t all?

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

Has anyone had any experience wit Javassist? Any thoughts/comments?

Regards,
Dmitriy.

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Sent: Sunday, November 16, 2003 3:59 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Is it worth keeping BCEL =
around at
all?


+1 - the Hibernate guys typically know what they're doing, so I trust=20
+them when they switched to ASM :-)

________________________________

Von: spr...@li... im Auftrag =
von
Alef Arendsen (JTeam)
Gesendet: So 16.11.2003 19:17
An: spr...@li...
Betreff: RE: [Springframework-developer] Is it worth keeping BCEL =
around at
all?



+1

Just get rid of if, What Mark is saying about the side file approach =
indeed
sounds like the best approach...

Alef


> Hi,
>
> I vote to get rid of BCEL as well.  It always seemed large to me.  =
The=20
> ASM api indicates it supports attribute manipulation in the bytecode=20
> so I
> should be able to port the bcel package to asm.   This
> feature bytecode
> libraries might not be that important anyway since the default =
storage=20
> mechanism for attributes will likely switch to side files instead of=20
> putting it in the bytecode.
>
> Mark



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from =
any
Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=3Dmm/g22lp.tm=
pl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from =
any
Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=3Dmm/g22lp.tm=
pl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] wizard validation

[dl <dlu...@iq...>]

            This is the method called when a wizard is finished. It
belongs to AbstractWizardFormController. And always starts revalidating
all the pages.

            If I have an error on my last page, I get the first page
displayed instead of the right page because the check: if
(errors.getErrorCount() - errors.getGlobalErrorCount() > 0) may be true,


            for example when I have custom editors. What is needed here
is to find the right page which indicates errors.

 

            private ModelAndView
validatePagesAndFinish(HttpServletRequest request, HttpServletResponse
response,

                                                        Object command,
BindException errors)

                throws ServletException, IOException {

                        for (int page = 0; page < pages.length; page++)
{

                                    validatePage(command, errors, page);

                                    // in case of field errors on a page
-> show the page

                                    if (errors.getErrorCount() -
errors.getGlobalErrorCount() > 0) {

                                                return showPage(request,
errors, page);

                                    }

                        }

                        // no field errors -> maybe global errors, or
none at all

                        return processFinish(request, response, command,
errors);

            }

 

            Regards,

            Dan

Re: [Springframework-developer] AOP API - How to keep a ProxyConfig honest ?

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

Roger,

> The ProxyConfig interface allows for the adding / removing of Interceptors
&
> Advice - but nothing to support the changing of the Interfaces being
> proxied.  At first I thought this was a lack, but then I realised that
since
> any interface is logically associated with an interceptor that will handle
> the calls on it, this is entirely reasonable.  The only problem at
present,
> is the way that ProxyConfigSupport deals with the interfaces - basically
> they are not all attributable to their respective interceptors - so if
> someone happens to remove, or change the ProxyInterceptor, we're out of
> luck.

I think your suggestion has merit, although I think it's unlikely to make
M3. I don't think it has to break APIs, so I think we could possibly add an
Advice (Advisor) such as you describe below subsequently.

> After more pondering it seems to me that one solution would be to add a
> further Advice - ie one that does for invoking interceptors, what
> IntroductionAdvice does for IntroductionInterceptors.  For arguments sake
> I'll call it an InvokingAdvice, eg:

This does make sense. Adding a ProxyInterceptor could be a shorthand, just
like adding an Interceptor is a shorthand for adding an Advisor that matches
all method invocations.

I have some questions about the interface below, although I think the
concept is good:

> public interface InvokingAdvice extends Advice {
>
>  ClassFilter getClassFilter();
>
>  Interceptor getInterceptor();
>
>  Class[] getInterfaces();
>
> }

Why would an interceptor be needed at all? The call to proceed() is
potentially misleading? What about just having a target object or an
implementation of an invoke(Method, args) method?

What does ClassFilter do here?

This could also possibly be another way to do introductions.

> With the use of an InvokingAdvice, it becomes possible to require that all
> Interfaces passed into ProxyConfigSupport are duly packaged in an
> appropriate Advice / Interceptor pair.  The only problem, is that lots of
> existing code expects to be able to pass in just an InvokerInterceptor...

But that should still work as a shorthand perhaps.

> In the case of Introductions, the present strategy for dealing with
> Interceptors that are received by ProxyConfigSupport without an enclosing
> Advice, is just to throw a config exception.  However, I think there is
> actually sufficient information available to be able to build an enclosing
> Advice dynamically - ie. the call to ProxyConfigSupport.setInterfaces()
has
> supplied a set of candidates interfaces, and the IntroductionInterceptor
> provides an implementsInterface() call that can be used to test these for
> eligibility.
Fair point.

>
> The same stretegy can also be employed for InvokerInterceptors, since each
> comes together with its target that can be used to test for eligibility.
> This would leave outstanding. only those interceptors that neither
implement
> IntroductionInterceptor nor ProxyInterceptor - for these cases, calls to
> ProxyFactory.addInterceptor() would still need to be changed to
> ProxyFactory.addAdvice().   (By inspection, I think these cases include
code
> in about 4 core classes and their corresponding test cases)

Regards,
Rod

Re: [Springframework-developer] Is it worth keeping BCEL around at all?

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

+1 - the Hibernate guys typically know what they're doing, so I trust =
them when they switched to ASM :-)

________________________________

Von: spr...@li... im Auftrag =
von Alef Arendsen (JTeam)
Gesendet: So 16.11.2003 19:17
An: spr...@li...
Betreff: RE: [Springframework-developer] Is it worth keeping BCEL around =
at all?



+1

Just get rid of if, What Mark is saying about the side file approach
indeed sounds like the best approach...

Alef


> Hi,
>
> I vote to get rid of BCEL as well.  It always seemed large to
> me.  The ASM api indicates it supports attribute manipulation
> in the bytecode so I
> should be able to port the bcel package to asm.   This
> feature bytecode
> libraries might not be that important anyway since the
> default storage mechanism for attributes will likely switch
> to side files instead of putting it in the bytecode.
>
> Mark



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=3Dmm/g22lp.tmp=
l
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: Is it worth keeping BCEL around at all?

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

Mark Pollack wrote:
> I vote to get rid of BCEL as well.  It always seemed large to me.  The ASM
> api indicates it supports attribute manipulation in the bytecode so I
> should be able to port the bcel package to asm.   This feature bytecode
> libraries might not be that important anyway since the default storage
> mechanism for attributes will likely switch to side files instead of
> putting it in the bytecode.

Yes, the new ASM 1.4 supports attribute reading and writing. CGLIB2 will use
ASM 1.4 (or higher) so you won't even need an extra jar. 

FWIW, now that the JSR-175 spec is public it would be technically possible
to read and write class attributes in a compatible format, which would
allow you to seamlessly transition from javadocs to actual attributes when
the time comes. Most of the necessary bits to do this will be in CGLIB,
since we have to know the internal structure of the attributes in order to
pass them along during transformation.

Chris

RE: [Springframework-developer] Is it worth keeping BCEL around at all?

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

+1

Just get rid of if, What Mark is saying about the side file approach
indeed sounds like the best approach...

Alef


> Hi,
> 
> I vote to get rid of BCEL as well.  It always seemed large to 
> me.  The ASM api indicates it supports attribute manipulation 
> in the bytecode so I
> should be able to port the bcel package to asm.   This 
> feature bytecode
> libraries might not be that important anyway since the 
> default storage mechanism for attributes will likely switch 
> to side files instead of putting it in the bytecode.
> 
> Mark

Re: [Springframework-developer] Is it worth keeping BCEL around at all?

[Mark P. <Mar...@Co...>]

Hi,

I vote to get rid of BCEL as well.  It always seemed large to me.  The ASM
api indicates it supports attribute manipulation in the bytecode so I
should be able to port the bcel package to asm.   This feature bytecode
libraries might not be that important anyway since the default storage
mechanism for attributes will likely switch to side files instead of
putting it in the bytecode.

Mark


> I vote to get rid of BCEL.
>
> Regards,
> Rod
>
> ----- Original Message -----
> From: "Colin Sampaleanu" <col...@ex...>
> To: <spr...@li...>
> Sent: Sunday, November 16, 2003 3:38 PM
> Subject: [Springframework-developer] Is it worth keeping BCEL around at
> all?
>
>
>> You may not know this, but ASM has switched from an LGPL to BSD license.
>> Given that BCEL is so big and bloated (BCEL is 20 times larger, 500k vs
>> 25k), and runs a lot slower to boot, is it really worth using BCEL in
>> any fashion any longer?
>>
>> Hibernate runs a lot faster with cglib-asm than cglib with BCEL. I think
>> cglib 2 won't even offer the option of using BCEL...
>>
>> The only direct dependency we seem to have on BCEL right now is
>> BcelAttributes and BcelAttributeWriter.
>>
>> What does everybody think?
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF. Net email is sponsored by: GoToMyPC
>> GoToMyPC is the fast, easy and secure way to access your computer from
>> any Web browser or wireless device. Click here to Try it Free!
>> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Is it worth keeping BCEL around at all?

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

I vote to get rid of BCEL.

Regards,
Rod

----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Sunday, November 16, 2003 3:38 PM
Subject: [Springframework-developer] Is it worth keeping BCEL around at all?


> You may not know this, but ASM has switched from an LGPL to BSD license.
> Given that BCEL is so big and bloated (BCEL is 20 times larger, 500k vs
> 25k), and runs a lot slower to boot, is it really worth using BCEL in
> any fashion any longer?
>
> Hibernate runs a lot faster with cglib-asm than cglib with BCEL. I think
> cglib 2 won't even offer the option of using BCEL...
>
> The only direct dependency we seem to have on BCEL right now is
> BcelAttributes and BcelAttributeWriter.
>
> What does everybody think?
>
>
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] Re: AOP API finalization - Advised

[roger h. <apo...@sn...>]

The only problem with the named Advised is that the ProxyConfig interface
actually contains a load of stuff that is specific to the config of Proxies,
ie. Interception, ProxyInterfaces, Targets, etc. - rather than any abstract
notion of 'a thing that is being advised'.  Shouldn't the name Advised be
retained for the generic super interface, as for Advisor ?

Roger


"Kopylenko, Dmitry" <dko...@ac...> wrote in message
news:3E7...@su......
> +1 for Advised despite potential JBoss "legal threat" :-)))
>
> Dmitriy.
>
> -----Original Message-----
> From: Rod Johnson
> To: spr...@li...
> Cc: Bob Lee; renaud
> Sent: 11/14/2003 5:54 PM
> Subject: [Springframework-developer] AOP API finalization
>
> All,
>
> I've made all the proposed changes (although not committed them) and I'm
> very happy with how it looks. Ah, the wondering of refactoring tools. 5
> years ago I would have spent the best part of a day doing that. And
> probably
> not have had comprehensive tests to prove that I was done.
>
> One last issue and I promise I'll shut up about AOP...
>
> The ProxyConfig interface. I wonder whether it might be nicer and more
> consistent to rename it Advised. (Now that it holds multiple advisors.)
>
> Pros:
>
> - More elegant and consistent with core interfaces(?)
>
>
> Cons:
>
> - JBoss uses this name too, which may be a bit confusing. (Or may cause
> them
> to threaten us with a lawsuit...[joke]).
>
> PLEASE feedback if you want to influence that decision. Otherwise I will
> decide, and I'm feeling about 50/50 about it. I guess no feedback would
> make
> me more likely to leave it alone.
>
> Regards,
> Rod
>
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

[Springframework-developer] AOP API - How to keep a ProxyConfig honest ?

[roger h. <apo...@sn...>]

Hi Rod

I started pursuing Introductions & interfaces but kept finding myself
distracted by the code in ProxyConfigSupport - & after a bit of head
scratching I've worked out what's been bothering me...

The ProxyConfig interface allows for the adding / removing of Interceptors &
Advice - but nothing to support the changing of the Interfaces being
proxied.  At first I thought this was a lack, but then I realised that since
any interface is logically associated with an interceptor that will handle
the calls on it, this is entirely reasonable.  The only problem at present,
is the way that ProxyConfigSupport deals with the interfaces - basically
they are not all attributable to their respective interceptors - so if
someone happens to remove, or change the ProxyInterceptor, we're out of
luck.

After more pondering it seems to me that one solution would be to add a
further Advice - ie one that does for invoking interceptors, what
IntroductionAdvice does for IntroductionInterceptors.  For arguments sake
I'll call it an InvokingAdvice, eg:

public interface InvokingAdvice extends Advice {

 ClassFilter getClassFilter();

 Interceptor getInterceptor();

 Class[] getInterfaces();

}

With the use of an InvokingAdvice, it becomes possible to require that all
Interfaces passed into ProxyConfigSupport are duly packaged in an
appropriate Advice / Interceptor pair.  The only problem, is that lots of
existing code expects to be able to pass in just an InvokerInterceptor...

In the case of Introductions, the present strategy for dealing with
Interceptors that are received by ProxyConfigSupport without an enclosing
Advice, is just to throw a config exception.  However, I think there is
actually sufficient information available to be able to build an enclosing
Advice dynamically - ie. the call to ProxyConfigSupport.setInterfaces() has
supplied a set of candidates interfaces, and the IntroductionInterceptor
provides an implementsInterface() call that can be used to test these for
eligibility.

The same stretegy can also be employed for InvokerInterceptors, since each
comes together with its target that can be used to test for eligibility.
This would leave outstanding. only those interceptors that neither implement
IntroductionInterceptor nor ProxyInterceptor - for these cases, calls to
ProxyFactory.addInterceptor() would still need to be changed to
ProxyFactory.addAdvice().   (By inspection, I think these cases include code
in about 4 core classes and their corresponding test cases)

I worked through an implementation of this yesterday, & managed to get all
the tests except a couple passing, so I think it is at least a sound
proposition - whether it's a good idea is of course another matter ;)

As you're in such a radical mode with the AOP stuff, I thought it was at
least worth asking another question - I look forward to hearing your
thoughts.

Roger


PS.

I have attempted to attach a copy of the key source files & some Diffs to
cover the changes I had to make, for your reference - I'm not sure what
will become of the attachment though.  Needless to say, since your changes
have proceeded apace, these are now obviously out of date - but you'll be
able to see what I was up to.

To give you an indication of scope, apart from test cases, I needed to
change the following:

New files:

aop.InvokingAdvice
aop.framework.DefaultInvokingAdvice.java

Changed files:

aop.framework.support.AbstractAutoProxyCreator
aop.framework.support.AopUtils
aop.framework.support.SimpleIntroductionSupport

aop.framework.MethodInvocationFactorySupport.java
aop.framework.ProxyConfigSupport.java
aop.framework.ProxyFactory.java
aop.framework.ProxyFactoryBean.java

ejb.access.LocalStatelessSessionProxyFactoryBean.java
ejb.access.SimpleRemoteStatelessSessionProxyFactoryBean.java

transaction.interceptor.TransactionProxyFactoryBean.java





























begin 666 InvokingAdvice.zip
M4$L#!!0````(`(T$<"\0KWFS(P0```0.``!I````1&5V+TED96$S,#(O<')O
M:F5C=',O4T9?3V-T;V)E<C(X+W-P<FEN9R]S<F,O;W)G+W-P<FEN9V9R86UE
M=V]R:R]A;W O9G)A;65W;W)K+T1E9F%U;'1);G9O:VEN9T%D=FEC92YJ879A
MK5=+;]LX$#[;@/_#-.U!2@SET=W#QAM@TS1%W4,;M.DI\(&6*9N)+&I)RGEL
M^]]W^)!%2G:<`@V,1![.?/R^F>%0&?1+DMZ1.04NYHDL!2OFF2!+>L_%74)X
MF:R_C0;]09\M2RZ4<<9%DN>,%"E-6*&H2&FIDG']Q,4H<-^$/2Y6_ ZMY[,5
M2^EN_XN<2/F!Y;C%;N<KP1\>7TRG4BQ/OBEM_(Z/TE=[2U;$.5 UVF#^2.1B
MR]*Y$.31H@WZA_O[@S[LPWN:D2I7L&;'>&%S``B0TR4M%-%&4 NB3 B30. 3
MPKZC!,U$IPVN."8^K1208@:>U,2$F%__D$HMN("O? :?^**0O+#V%152[_!F
M/#NM"77Y)%K)< 7'R0F<'!V]/3P^/CP^@:._3D_^//WC+=Q:2 &7#R6\T<B'
M@WY937.60JJKU4#[I6YD2@A7AN 5&?X;]'OXP5JMB**^1&!!93TG+(1=S$A*
M)9Q!0>_!52B*0U]_K]1[/O-7DNNOWR]=G%6V45,4&[H_=SMND>&D:R)/3S&6
M7O![">>\O.!%QN:7#ZXR9IN>I,K#B3P<K;'7([/9N,Y"9"%'OX4>,WF]F5BY
M/;5@,@K<K,,0,I)+^ILW'<*4\UP?`=3_I<@?QW4CT4:NC%^6HGK=Q$0U[6>!
M&S7F+/?T22H)3A&?M+$?-HI7G,V@16:+7B^IB6?&A@S[O4-"TNTC/$SUZWG(
M)&[3]:FU?2T]054E]' *679*'0BW6=[:0\GF:FQIHIW(O]0HC1!C35(,%)%M
M$I:!(P.O<)94>>Z">E^FMS15.(L%9@GLF@DQ,2_8UCIV:LT*J?2MRC-HWV'K
MP-YZURCJ.K4AXP1]KTV$4]73Z5PS<%BAO+K,@;_]G2%+?9R (8&C$?[YVR4^
MR6DQ5PLT'1P$*E\]EP_X\<-Z@OYQ)623A,ES*=F\(-.<?A!\Z9AJ-:;:41PW
M;(.!M\:(N_1_;FRF(-SU4J&RG7.XW3N($YG 3L\:T)O)^DS9M@V/5.2<_!I:
M7,7-JT2D;S/KU/:0[ DOH<G&&?7<>'!C@<DK*L:N][I3H3Y.+;=P((B*;I;M
M[M6Z</;KAG'RJ]P]M-=+HM(%9M2\?.6DF-O5K4IJ_^#6W2G'OB."XO:AUF"_
MO:NR#&7*J7OM\*U1T[6Z@3^C# P^@+U3V'/WT30A94F+6;2YM-K9>[4YN]E#
MB_?.FJ0\SW$D86]>\PN^7)+W-&=+AF?-D6WA&L3)J+O_GC<\SO0NG2&%@9OB
MRJ8W;!RFT#JYG*)OD[J12:P^C]WJT'\K'/V1&[)<+6@]_<PXB8S%GY7A+1?K
MLJ]W-;>(H=%Z#]7OUWJ(MH+M?NOYK[V23N_B=6#2TE[8LK.A72,%EVKBM-9H
MP>(V.&>P_U\T"!Z\FR]#"'"=M9X2^/D?4$L#!!0````(`'&I;R^$_'AP\Q `
M`#I'``!F````1&5V+TED96$S,#(O<')O:F5C=',O4T9?3V-T;V)E<C(X+W-P
M<FEN9R]S<F,O;W)G+W-P<FEN9V9R86UE=V]R:R]A;W O9G)A;65W;W)K+U!R
M;WAY0V]N9FEG4W5P<&]R="YJ879A[1QK;]M&\K,"^#]L<D5#)SHJ:7&X0QPG
M<9WFJB*-`]M%[Q#X`R6NI+4E4L>E["A%_OO-S+[)I20[1:\%3@ABB]R9G9F=
M]^YZ\&CO'GO$SF><G2TK44S9FRI;\)NRNF)"LN5J-!=RQG.V*G)>L1K&U;Q:
M2((J)_3@:)F-$;Z<U#=9Q=E;,>:%Y"F.&>S=V[L'[Z^R*6=E-4TES3(QDZ19
MN4SMMP,<+1;+LJK997:=I:M:S-,?,CD[X_5!Y-40B,GJLHJ]>RN**YZ_%3(*
MV?6\8Z*CJLK6TJ</F0'BL_E<9,68IZ(`6L9\6:=#\YM/5_?PGW@]*_-N())N
M.BX7B[*0Z;R<3D& Z=MRNNNX-]D8L*[#X;%U.,JO8>FVC[.TBK*X!4Q5YJOQ
M76$ZY1,#?%^5']>W@A@6U^45/-V5-/=-KI8X,CT#B#F_+9M*YVI\^#/\JC1L
M\$A9Y=EJ"1S,,RG9I*S8T<E[1IRQ<5E,Q'0%J@_3L')TR<>U3#7,B""X9&B+
M15DM0.?6;$)*(.#QI"H7[&8FQC/"N"2,HI UZJ4R;(0L1W4F"K#\7%2 ?KXF
M_/3Z^?+%$)E=\**6;%B(6F1S\0EX^(YG!2/5AOEXRH83MI+H5<I5+47.648(
M<)C62I8H4F[$?,[&0"JX%' \<S'AX_5XSMF"S(-EJ[I<`+\X9+W?)S2@[^,K
M)C7'+"_'*R1)2263K"Z!3P`'QR7JAY(5'!B4&4P*;Q"18M9,(5= !X!E$Z ?
M! W"KT%@X!&2?8(HD>F:`X.:8YI)(4$8AN3_"#Z#Q+"T&-@,L(XX+YCD=2#&
M<^15KW#%8:1TRZ>]ZZQ<27[%^9+$.&'"J34LUG/U47IQ3&IQIA42G9>BK<C9
ML@2X,2Q"GXU6-8B*R^)AS6 -5J0>XXIGP-D;HQ% -1!ZJ#X[8Q%&*UB(!\!?
M2;Y#`$B/RB6Q<AL8C_>]>R_4ASU-O[6"?@7*,P,#.H5%_K&<%5(OVJMK7DG4
ME:^&^;,N$?:O$1?[YLF3;P=/GPZ>?@._/GOZ]V=_^P>[5+@J]OW')?M*ASL*
MF6.]J&V<3D;!6_8K&GX/1%:#L8'53421S1EX;X:>''3KD#E7GDYY#=\2^'&,
M\R3[^^0X``/X#@8_@#N,<*@PR@V1+8)6>EX1`WR6YSSO@WDH`QQQ=E-ERR7/
M%0Y1((S"`"_!"^$/U$0"1*L@<\6Y4C7O@-@0UZA.1$)&T!(8*/@-<U$Y4303
MQ4/C,LAH@0HK)9ADM"9#4(XJP ^FZ;R-F4&G"QK]8,"JRYD'0P+[<,$J_I\5
M>+9\V(17`YY<'#A@1:42R4_9&@DL5O-YRDXYV:H$*M'EY#F)IO"--&U)Y83\
M-:NS:DK)AH_]#,Q]GAO3<4Z8G#:).O3]_..RE%S!8@P;J\<8+B@U*Y>@7S7_
M6&N%!.E6',(-O^9J$!$A7RH,F ;F?)*MYC4JQR2;2]Y'E\B+#+0:>",2M&=;
MLT6VUGJR6&:B8O!T@@$'$YP6VZ.RG*-?5"0[8D$"O8@(;LR*4\Y)9&H>@)X;
M#LJ*KKI8>PJ@N3B&2<!G*EJ!82 )M/?XGV^'WRF4R @(`)9I@M/,LFONJY&)
M`\*+Y;*;'T)Y3@22ZFA^S#"3WAEV3=Q;Q)^WI %LHY55*X[!K"!Q3$0E:R]Z
MV_BBW#@8] (H4^N5U<CC8B5KA;"N(!O71@D1-"NFP/*UR)A)6([I&80\C) C
M&-S-NI!'()UKWE#B=R5D$%/45 ET(UO(`F K;VAA<.$H3@+16>&A5ZZS[32!
M&/"/O1Z$SPYQ)L;R?\J6QY (`^]=(\E7]CXK.?MD[T#'+1=S.]E=@)I$1\QU
M*7*V`='=*$,323N&@#O<H*,1^1W;[$TG5.@2R:6:[-+HIW'I1?E7HRA*3[2*
MEB8?(5>:\R6'_R"K&)?+M<F+`C^HX+23A)P!<SZE5^PU)"DPD0;N$-,!$+K,
M,*/ -$XJ#S0B#W0M;*#CODHK[.!!;%:9@N+77)D<#I: KM/\]1S/1R^ MN>#
MT0N<#HQ#!U[CP'WI]1G&[!J]+C&$8=()1[/[BMA0$F"OE2_W\PS*8Y?-$@(E
MYUFY24)(Z7#XL3_Z#0Q.(ID-S>DK5M/3@T:IE8F$`!=L!P.R&!>7DT3'['T-
M[GQU6I=4F2<N<+>&2/$)O-F%,OL&9C6XG0JHL<2$APG*D:Q*U#M<H,2T'V!5
M*$-KS2WT``"B,2EXZG<0C?&[EE0/L@8[L69U7PTN:*2:[[.7RBC"-N95FD @
MA0D8\02F9\\U?1I0"P;>/'YL:-&9GHX.ARQ1#_8;D!#J$J&F0?+5H$2]M>1J
M_^7<`YDTNOZ(6MZ(>D8*/Q48F*TMRE"MO2AM4D(!>NH>!Z-;^F>JP6AJI!-@
MA6$E(>'AY*=4ZJ&+;&<DG3'"))B.J'YG[N,"A*>4#M"J[/<-N*2%R 4,/W60
M.['<R6TH_)8X,5UL/00'`P0WY:3*&1/$6NQLD4^7-XFED@TAG/)Z516_B1P\
M=@R]TP@OFN:*)NXB,0B<MZ]S_P(3OV_DG<G^!BK;@P,J2<"Q1+9)*J:C5I1E
M5X9N6D;=J;K6K%\@I&;4%K'9.F6Z'5E[:ER'K4X"!6TR\)M0VA2JT>&61+OJ
M`5^'6Q0>1LN'A@[?03],4%$U:+)3L[JE/\1J`U/0/_!@%9,8;T#?,7($,>K^
M(17,^^PE\Y_K$,2>08!"\,9<@*D?3-*1>-Y!/D):A_M>!9&$FOUSJ'U2M6Q=
MUA0!56L)E$XB9N4G$.!UH)XG%S^)N>PO7VG W-]M;T(QB-4R)I. !KLPC7X[
M=1F5:=[H6G^+?F@-Z(>-IH:BN$RFF7"@EI J0&*=W$]$@$2EP9#_M[9,]DT"
M4\\J*#(Q(5).'B3T_4>]5>&URS"#>0?2!-U[S!Y H3+'(KK(YZ"K+>3R@<MI
MB*X.JMKB\TVCYW@$ZKIV"Y*D$XLW:S_2O>J3YT1*0;ILBR0>=,PBJ;@@<8RX
M[O&!1P3W2JW$-KV^:#CX8[9!/J2UVP2C'7RX'Y,D;=B=Q:$JBBWR:.+?(HB7
M\.D0`/'$X!-G2\_@%MRW#8?*9=5D3"ZUMJ;SV31\!^S\Y/4)Q#HH.[-1N:I!
M&@LH6[$3V9+YR[U&2F:\&L%PWY(W&7"O%\+EP";%8^(@5GK$W/[77[/[&GZW
M*B1 XA<AJ'5Z>&B0#6GCE$G2?KYO)(Q8?2'LL\/#"/=A"98J)BPU/2<45$+U
MD);5V4B4VH9Q66H;SYO4QBSYCI1'B! 9+D$W%1H2]/ 7[%>H9HG"&Z91/4\S
M+I5F7()FB,P*7=4_^^F<%]-Z!J^=3ABAVG%)&^[#Y87AX_/&A7#Q9_."^#[(
M+(;_[#=6F\:$1O"Q&?_40K>!5(\,`X'J/^>)]8;X0R=4QEOLQ8I=RNX=\WHG
M2?<(-O810J!(^6J2?H_Q=IFO4IM'09/&O6UWCQH>TAMJEL+SB4&7R W]("ZL
MG(A@->V6S:W65!>$XVPM:[Y(,^RH8=?/FZ?/GO19!VIZUT(92V^/(,E4'>%6
MYR9<'QAB\=.V&KH=B%9VN"WI6J5YD)22M%1V[J/T2S*/<(!*@F$DE9A6JCU9
M@)V4R8,CR@Z0JTPN<6?/HGP&N>5CUD+9:E&0V6:=0C$M;-S50%\EL/[%C?<N
MW9[H!]IJ=*QN2BH2^CUYB:W5C'%?82T39!?&2'0'0OAJ8UH0@X'&[]J\S9E,
MEU<)WR"E"KZAV4U(W?PE.&=OU@2]!B[V;YO08?O6Z]ZR`V.72EA RJ=/Z*UM
M^]9T;Y7[TZ1^`(.^@&$TW)BME:\>9$7IA*EWC$&*JE$0Z][8[613(3?LP:6;
MC?K,1?K,IEF0*LM(GJP<W-X][>%<V&S'OQWR?@2G9L%A+#L,0Z9NVH"$(Z5 
M!PT4E8W ;!CR7*65"H&!OC:3;:/2>MLS%*4%LB)MB-'Y&,,9.ICF%#'_XGH<
MVQ>QF:[MM(B4.1S3\2FG[N: !VT*JX,,:^USS"$S!HM:<VL^(HQ@C7705AZ+
M9E3=QX=#1$N]%DN@")LJ.&6(#]'A=B,.ROZ'V$6DWH=W9NT`&Y)Z=PVWXY@Z
M`B,\03_PE:G'VKS$\_'4G?QQW'62:MEF=ZODV8>6)#K*!)#$!<8I/5NO]R W
M6Z;N/)>5SRTEC %13%10"X2H41A9,A*F^E^KYY .9RPS.EUCSC%@MWB177&U
M&TLVTV-?KH]APM"]*,9GV[W*1YK8>5E>V4U;Y:RB'K)C#?YGWC).SQ;/.;B-
M]W0'L+:YLJ#X^;\;^QW=F%+CF"O['=R76O:-KJLUY(_DME0NP72A>@O']?N[
MK5NYJC]-,K>C*W*'.5OGJB+NJ.&&?@U%Q#9V&;V:7:,EE)OZCFZ%;M4AW#!3
M5\]PQYG"IE-\EFBOOFLBA6*S,_BYN"K*&V-DK%XO6X8;W<!YZ'7A-U8_T56U
M>Y81Q3T(U&O7Y'WOBS?WU7R1/7TZ4NT/L'&0=@&TBZ$;%#!P52S*'!P9'FO 
MUG]0,6I.(S03*KQ)1,?4?_GAZ)P-W[#A^<,S=O2.#=^=GYZ\_OGX?'CRCIV<
MLO>G)__ZMSY[>\J7<W2WWE$>?6=@+]BI'S^U+U3GDL :8[Z)C5%GU>O97JS%
MX=WW8#>9-# YG7ZG$T,!-3 $VRB3<E60I\<1<WULWKOK0/)49QH57*4/E="6
M!]V,R+T63:LEU=QI(9H:&FD]SLAS-O<#C;2[Q]G^/AF3YMUMO(0*#)XR>("'
M!3^>3 "\#[-TJ:]5$=V[;:C&4&\'"R]>BV(\7^4FR5A;T;T,UG,A`B \B*@S
M-X"F:QAEO&_EG=UI36S.E>H#FWIY5H7-=\RYFRV+XF$=:FZ"#;"%\)8EXB<P
M[CWI6)4=M\-<9 ^KBUX[;!@'>1B/*0'R:72;K!WC@0%@DH8U5,"D.'?<EVO,
M9'QO]WR-C8*F/!L*>0S&6_OK9V].*?]#7;5 $;VQMGLG+51,1T.UQ*6D+(YF
M;H-I5/9FESDK[.YVQ751T EGP.F)2YY,SB$*NIYL0/EM=5)U/NT\82_T#Z.A
M32ZACCJ24DSQ#@JGP\<=.NSE!]I#]AX_)DX/OE"'MY,4U_*-%,7UW+QM5L^Z
M!ZE4Q7=-C9D#!K6"^,-]_6Z<M]%"V2FW#='<;D_=YFIW2W8C4]]I@WQ',F*9
M<)N$W;:%W93.EYBW>LUC=\X(/<17N@"D:<0[/ZJ.S-L7=.2Z&$.F78#9YB8'
M1B@;Z1N.PUSD,?S1PX[;'VG%)Q67,X+4-A+>'?+V;FTZ'K30<2[X9L@(2/"W
MC6]'A@H,OMR\R]#ZOH6[80R^'8M0M1UIKU*E>*@Y<CM#X7.W4MS=*WUR74AU
M=!1O/M$M9+,IIQ;:6R%SN2)8(W/O54]AOOH+=;^Y2$Z,+;72!9;"@<3UD=F=
M;D3%A(?-B_*:5Q5>X?:R8966CSDN&P@*"@UWT-XJJKYCIJ^'@GPQB3,=&C6\
M(WL.[Z&T=(S$L(7J8+U5OFFR2<Q4O6O*ZAJ@?XN.K?V#`(V;N<TK<(TM.>]F
M7(O$4U.#==\.`@;*L2 BG'YY)>(VW>K"NTD)`OHW69ZS-<O2&_"#.1^MZ&].
M#'*138M2UI#9K/01;2_947_M`-9#_6(F5M^^6TTF> -KI'=U_:>=YS>?,5W_
MRU&*EY>+7'LU=*[4!C,9$1[V=$\/J='H_?4%*+'F<TZ1XKP\AOHW>\WG8B% 
MI)K8!E[5ACSHF+^1CN'DMJJ\Z]P:9^?$#U1S3:$G"-UMZQK?O*!PB("MNQ8`
M'0/NT)!#._FF^XU&UP"?4X:8P=RAA5*7WC>#NU,3(V-#:VB2!__^"U!+`P04
M````" !QJ6\O=Z-[+F<0``"5-@``9 ```$1E=B])9&5A,S R+W!R;VIE8W1S
M+U-&7T]C=&]B97(R."]S<')I;F<O<W)C+V]R9R]S<')I;F=F<F%M97=O<FLO
M86]P+V9R86UE=V]R:R]0<F]X>49A8W1O<GE"96%N+FIA=F&]6^V3U+89_[S,
M\#\HE\S@#1L?T&:FA=#DN "YE'!,C@R=89B.=JW=-7AMU[)O;]OPO_=YDRR_
M'9"DS8?+G24]>MZ?GQZ)XR]OWE!?JI=;HR[**LTWZDFE=V9?5.]4:E79++/4
M;DVBFCPQE:IA7FVJG:55Q9H^G)1ZA>N+=;W7E5'/TI7)K8EQSO'-&S=OP/@[
MO3&JJ#:QI5W6;I-8%V7L_WJ L]-=652U>JLO==S4:1:?5)4^/$MM_6!D\+3(
M,K.JTR*W8\,_:+O]29=C0V<@B*Z+:FQL:C<FY0=0(!! 9UFJ\Y6)TQQHKDQ9
MQR>V!*X>7^$?P-N#CUARYGX+69J>_I.IMT4RN6A,SR?))9CFP_. :%4D#6GU
MDS9X4157AT]:T?YEFQ)GQA>P(C,A"Q_#]M+HW,:/\.>$TL=7K/4*^#S0RB?\
M^V]<=H*^_REK91V2^)1EZ)IZF9G?R+%3<[#\%_!L>SV-55&9^+R"%'!:[$KM
MXN;FC>,O.8$$PB@RX,[DM48KJ'51J<9"WBB4+1KP#'5R_D*5X"JIL6I=%3NE
M7?()N*+T0;2_*?\6^)15F&/2!.BGZQ0RT_(`ZR%+U9B/4%B5`]M6I3EEIU53
M53"71]8!;4QZP!:I1]EMT61 RU!2.Y1&!5N"2A2'VXL"`G#5U#%ES$S#ID"[
M.L!F1!(W)%96L!D0P[^1&Z2J\P,S(8PY7M396J7U+:MRD\+W"B:&FW.FA:\]
M%A;P)3=[F'I9O#-5R"XD;ITDH!I0^;[2)9#O:/-I5BQUIM)0J<(PK]-UR*'*
MS*7)6&1,:ZSV(C=D"B)JKDJ=XTJ0C21LF2%U[$$N@R-'5U=77QXYI:&15EDC
M"YWR%D1RI^O5%GT"/V_22Y.#SYAU>J7VH";Z&A@[,O$F5D<;D@PVV),YB89:
M%O662,HP.MG=(^ F";_<.UJH(U@)J58EL$].3+4:FK,"'%M$L*/!C:F5+LL,
ME:-7$#$)<5\@JVFE*E,W%1(M,(S4I<X:LU IE= #4W-Q0\)1M#D>P!(F5B==
MS9)CD7IW^J#R`KRN8'42.5*35BRA4WRI:R"0@_-8-])W`R24DE.I6E<@E>TX
MSVEE=(VF5S_>NWA,<7Q ^^;RJ^>7`Y4LA[YZ^O39V2.9@RD!9"22X&,-<,%;
MJ17$E$6M`!>Q>E[4&$/BCAGQ#G*!A8H\@UT)I3 ("=<3W:0`#E"6K;X$5TYS
MV&1'$61)>JV2`V@P72G;+'E;H@Q!L"(1*0RJ!M+,SG23$09K65B;0AI&`Z\P
M#VB1K5C6FIR',EN]!2=W<013J4*>%ODZW2Q<9,-G7D2"T(PPG8+3@R- \2>/
MA4TVD);!#=,5N.I!8B5/RP;T8S#4P4]ATWV1WZI91:AN<P6.@@X)!.J",IPG
M# K9;U.(%,JL$,>ER3&_QNJ'8@^Q7S&K:<T:\C0]*8LZM.9?#2S*ABH(<MWI
M5N<;F \R>[^#(B$.ZXBGNYU)4A 'B>7*`M^9J0'BJ8@3!@KB)6KEF+<<DUUH
MLS92V2M1X^PLDG7AH]5L'K$#9]8TATJ+>D<Q?'KWHI"6=U0]R$4]EWZAG=8$
MN"<Z)U$E!\4Q2Y5B^1:0HQ2X^A!*!(D"UW7G=\(7/82%6^#O1)ZT@'K"`M0Z
M$VF;-40YC_<-8OT[W4"T5.KG(E$_%MO<BIG<]Q\;`QOEP)\!",YUZCM@U&+1
M_^(LN3]PY1B!].)2W8W_HN[=N?.GX[MWC^_>4W?_?/_KO][_^FOUEG>IU..K
M4GW!!*TQZG-KZJ"^/<>,WQUM@2?9& ?AY$&GEY7DE$%<F:L:W-R&(7G!X*C-
MQ#8$-HL0GA#<4_]!##0C$#0C1)%B**RQ2I$;49:?*HH0:1##-4<#5U#)R6B%
M&8DP$QDL@JF5I+&+FL#2TV?GCTZ>_?/BER=/SOZA'F+U(DPV`RQUB;E@6109
M2MIZYD-55XUYT.7Z?)\CN1 @N80@Y0!S(GD*Y,1U3>? U/)BYZY8RM,ZU5GZ
M;Y,$[ LK@>9HHQ:YAIS \8HCA4#.:8-@M*,W4)0O^CB6-UFVX+6<M5 0D)/Q
M!B8LR/2,.CD&6[0E7WFQH%!/>^&376X81RTI7U:&#L,&#KP*ZX+2O![319M8
M?>(`K4@M&6H$964>\+>'1$).J]&\IQ?R>,20H2ZH&@@8%!3;0Y:\^'NSUDU&
M)L*D+1[&#D>QBK5TR!\[V>LWX9[,QT-2>]?53C'&8#(J+VD#L3/7BW-A:H^,
MK>LB!!EZ;VZ!]:B<`@MDLKQH)S 1$*>'+015.$0Q6M,'@759I(D:9I"H*SY^
M(^'GL$-5[*WJ'? 7K $`+$^*)D_\=\P0QRCVS&DH[2@'C,X#W6WBS.2;>OOF
M`:Y$N:#N@05AQ9T'\+]OU.AT&+I]>XY;SF:S=I_7Z1M82-O$:S9BU%T/,^:T
MU>SX&$JT6;WC&'%92[0.1-<J^JQ#.4ZMUUHTG].L&>F(A.NI*3HZU0XH$H1K
M:=U71^JVZG)]&[[A889M><0\OL<?KB*PL=I5.(7,.\,4%8^XX_].XV,[_M&Z
M'Y+_@PTPPO^D%=Z/A[4[BY^UB>.X>W8-3FX.1S6V9BHZV^N#Q9"U2*_@WD$(
MH]TA6O?/]..1';!!"H\F,YL8DNS8'P,K]C\]<"KHJH% R:>WCA#&!-^B3Z(P
MGQ(^I#A1@T.I@\\@\*!0S[)BLS%5G)AELXF.T.!AQT:](DQ)4*JI.M"4"U0<
MQ^(^G(X#T\#!(,U=X7/[I/FZB(X&R(UW8']%MN>!)5H[\$&UK2W"R HWXK-\
M\)DQO'@@L!YB!G"T4'6NHHS `5E_#1R@_DH<AH;@*&Z\]$]W5&V:S;9S=#AY
M<<:-%US7Y'J]A@CG1IAM$+3Q&6M8TLDIIC3O"UM1,A@.:AN*;SLU#8V$"6DB
M5KCLJU]_5:,3)'OBO#MSR9T^80WVCXX";@4TH(TJ.'"FE4F.G-= `GTJZ : 
MZRW"K=BCNY;9U]=R^)6Z^R;&8\*KM-Y&'<0];_/^=;R_Y+.F8U8`M*"P-ID*
M_S^!;2I&T4.O96]L<^?-B5)UG42=BB4'"4+3#\>700'@ZM0-_5,)<EP>\GG+
MU1"L&K>\94C]^/E#NN0J%PV2D8LA*"LC#?!V^0>,@<6/RAX6%>E_.0QM>X<-
MZSIH(QN*W02,S&8FL\:S`*',;L@7%U$TQK'JB[B0U>J#_Y$>L>%"UHON+/@+
MVQ<"^:ONR= /S+M,\\^0<_"_DR3!_(4@(-0%CY_S64^36,YA`A'B#1><B4#S
M0 <VZGH3[$JM*0</>J>^U^A4;O"\T^H&+WO3"POVP2D66K\44XF16*C%Y#I9
M\?[F./;YF8N!:(Y/8[[G,RP_O.B5\<?+I&",@YV>@QPMI\L(+W<=9>IU\1\J
MH9X8'LC;'M2Z0\0A.Z81'B*G*H84NI&207Z#WBT^@2@)?(!5:J-Y"Z;=92M@
M6\A^#]W\.)7O,)>&XJVVS\U5#7^[F&9JK==%_&'.\W.>'*8SU/YS3FF"]23:
M_'$;'54L+DLQ[?AUGW'Y\DFE@T;$TKYCPA8GG_,$NKG/Q0U-OR9JW/)VH8CN
MD<:)TP%W75X6XKRXLHTM]0K;D7I90"1I@O^!V3_[5H[7G ;+1-=TFX%+*U-F
M,*<7$;W=@WW^;DS)(;?398D::4IR9G =GM1JO&SJJ$=IH4*)IS(2! D7<\[L
MU+AS0 2[/-3,QRB#E%[130CU1^4B"Q(+SM29I]>F^P'8VAN(0]SJ78X[H0)'
M'."4>V+K-$^"I(->WCOD4-H2MZ4\1;<D5>L_@[QP%"IB),M0=@9<-79S\S&1
MW*],(X4I!/T+UVGDBS>)!W]\8BZ<N.Z4%-"BB^78&1F.J=*Z/\&\A$Q'G<V8
MJ9A.F:R(WE9GO;3\NW8+B(5;4C;C_,W-`O_Z)!J1U\'$VQ,<RCB3QCY?+GSW
MNWWC0&YZQVM@W,@B#^*ZF6@L">5M.)(68O"9,+^0`!3-^)&A1]"7F99B0C4?
M%*2_[O\G2_"T"$I'Q;/L@FS7>PL1S<=KG3#6KW,C5:XK#4P9*6QYKZ@Q_UC+
M`J$\TH;0KFK&VA*_OJ"UL*<O^+6II[V)#S+/H@/;Y#J ;[T["0Z[0H)['IF5
M1@#.G5]J[U3&R)5JFD'&IBM)G_@1N-!]5[K)-< <.?KN"CRHUU61;UP#6WV'
M!MDI5-XTDW+]Q[SV%J**@ZR.$(ZO0O:FO<TCJ.9N/N!$T8#@=(G"M&C]L"W5
MR\1B`3$\<NSS+=F#C?7I0)EDYWJ#YQ>2XW5X+'LC98:+JT.@FI _WY"W&]B"
M&B,DHKS>::\0Z2T$'T.!UA[G[0T71E*<;4I@C6_T@U*%\_N@3FX)T#7'(0Y*
MY8!1'[5[<7XV^.R"?,5+`.@@,79EZ'F*A^3LQM[0L1"@7B146&R$-)9Q-0/[
M,7=>>->XU=X4"24`]!")H Z^K2VD[S*)ZF-U#EM4^]3*JR&S%THC)P!ZW2(-
MCKIJJ(WK;^T15G%\0?[9I9MMW9I,2.(&195NZ#;QNI."6(S4TX/0F#8=1/3Y
MXWWG4DB,W+-DX/#BXQUG(%M2$N,8]N=^!_LYAPV/`SC?)6^0L7J[Q3\(38Z1
M.QM_Y#B@C^::>I,819-4.)Y1,4$W?4'7KT&)F>1N\+K37^N,3.X_NPSR?""$
MW /2>S&$12+!R$X?Y'T$J8]O)40#A4ULUZ\^(6TP)CVY0=2MIW)?W)DJ5P.4
MNC NY3J%7LHI7>$5'3^*XS4OS[\_5UO _'0,QXK$+3LYKM"TL7=VJ<@['//Y
MBCWQH_63IJ*)CS!=FEYOI./C#W15`=YL\.D5A/M]5EBW?4>W,BIX$]D[X( *
M`I';7F8;?=*5:"-[T#;A<;Z1BD61"9^45EE*3S#D40X!*5XV?%J%@ZZ2?]S]
M2W"A\#E8F[-2-+A(D6P5S'"-<ES9;8I[>5V/G2,TFH](+K<3NGTMY)_3R^O8
M@W]V( \'EX>.S"(N7V2XPN!NN_%%?D*'4MT^_Z W0:X0`<MT;X%'7RY;0"P4
MDQ>S842S(I[K`RHNC2W#$#&$F.75ICR]Y<7X@D5D;&5HM2TE0TCW%2AUHB@I
MU<EN`6KPW7TOZ[Q-'B\#M+;RUT=X045 @6@E:07#6$CY>8A;NS34UK#82["A
M+FF"XX/9=>Q%_03/G$RVT5RT@O>SVC1C8]U68T+##JDA=FE9=XO)DSP(&'B5
M$UKS<SNI)*ZQ8;]'?/DXQV9 XF^1>RU_%!*UL2K*0Q<K?-P-W6PV\M2*B'&6
M&XXZW>"D&'^<AE(\@2P0!=2]-6CVI$G$B=FQ-_+R8S1&?T\F>0EZ&683>@B@
M>I,ZJ2."0;XR@@'?B/R6NX;!&/Y.U&#:?1\(OU^ U%XX%Q^R[QZ4=29UV.\&
MX0A+[I$`OXP3YVP?J(%5X,R SQZ?%I>FRBV6`@3&P[3AWNS+@P'/@+R++.4U
MLH1!Q% =@1S^LP,_C<^"+"D6-+<=8&>A[VK8!'!WAX"6LKM'QCWDJ(EY-P34
MU*=<$LH/\+?.;.&?A-,5ISMQWFS+7LL!56QZJIYRD^*F%(3V#(,Y')^R8T "
M4,WX#9G+$BMSW.0IOMHUUC\>DT2YJ72Y[9Z-P]PW^MB@=8K!R\/PD4'X'''H
M*O#COU!+`P04````" "-!' O.-^&)?4#```7#P``= ```$1E=B])9&5A,S R
M+W!R;VIE8W1S+U-&7T]C=&]B97(R."]S<')I;F<O<W)C+V]R9R]S<')I;F=F
M<F%M97=O<FLO86]P+V9R86UE=V]R:R]S=7!P;W)T+U-I;7!L94EN=')O9'5C
M=&EO;D%D=FEC92YJ879AM5?=;]LV$']V@/P/5[0/<NK(=KNB6+(`#=86\S"L
M0].B#X$?&(FRF<JD1E+.DK7_^XX?DFC)LI,M>TDL\G=?O[LCC^.CPP,X@D]+
M"A>%9'P![R59T1LAOP)34)17.5-+FD+)4RI!(TY3N5)62F1VX;P@B9$7F;XA
MDL)O+*%<T=A@QH<'AP>X_Y4L* BYB)6UDE5&8B**N/E295$(J4^-%%N9GW!-
MUB0N-<OC7XA:7E"SV=GJ63Z7DMRJ4%N?"S_G1*GW+,?@3O>"9UQ+D9:)9H*?
MIVL,]V$R^)O*A!9:2.O;^,AEX0)UY!2ZZL%NK"C7Q"PBZT3#U2VD-"-EKH$4
M1<ZH`BV \%M(3#"6?GA#2KT4$CZ*%'X52ZX$=^N*<=0[G1[_+M;'+R:3EVYY
M3:4R%I[-TA/O3]>=V# \6L,T?@E&=#R=CJ<O8/+CR:L?3B:OX=H9DO#NKP*>
M^3*PI90XWWHU-X&J+32,($@3_&VH&R#5:Z(W20OX!=;BNA; DG&;&4F0NC/@
M] 9\B45#EY<QR.ME(!.:3X+?9^%._.GCYW?>EHNY+]IH:((8?&\LW4/F'H$Z
MM0-%=0\X"L&GSH7',>U39-BYNWNX'P.2IK,J*9%3TOAG^V2 9?I%D@*;``^H
M0 &6?FJ^K2$*),^#_%JY\3UB?$MSNL NXXN^:%/&FL#VPB,#KT-H*NKQJ&8V
MP,NY=\K0$FW '& $&<D5_7_27?DP@BLA<DHX(#<?>'X[J_J9-GE5_Z(N'-;+
M1U5$.XUT`ET+EL(.H[WQLH#:.*RX,]SK-;._-!Y8:_LJ;)"AA*$.&'HV.<5_
M/QD-\:*1#1F*AG%.^4(O$?G\N;<S\ GE.D,E.Z4OV=R:W6Q:(^G<^;XC`962
M_U ^33;L:IR@H(R<:9:!+Q)X@B=[F>=5>-LX<LAM9%A%3W8Y`]^^0;LNXN86
M"WAQ,;+YL%;>(JX&.%8M?_ZOI[)[35A*-]0T^>OA"=%-DEH'ZQM%^\>TL/[<
M$?$4:R.X^:+A8>N8#2_,-M9Y)ZDN);<4/HX_?5W2\:VOYW;IV/ YR/BCN5XW
MUU8F+^?0@FTX%'G0$-HYU\*.PI&9<1RHC5#L#N>1^8.+(DCITQ71^!!0D1W 
M<\(7;K<32]7D%;X[,E15(4NZQ:&W?NS-[*5?W_EV-#:/%BJ/&5>:F FW3A(S
MD^_><'PRF/J#RIG7T4U&%4 +UN][^]ZO%- _2[R4HP]7US3!MP.^IJKAS1X\
MD5V!*AA\;W4+9VB\JZW:.]Z>'UVD>S:<0;1%B;-=GYT&&7<:%H]26S;MC1X/
M; B5IMZ6BCT'E>9>8)\9O^#>>HVVVFS=*R,(;-2K5<4W9RM^_ -02P,$% ``
M``@`<:EO+S$AN!8N`0``XP$``%@```!$978O261E83,P,B]P<F]J96-T<R]3
M1E]/8W1O8F5R,C@O<W!R:6YG+W-R8R]O<F<O<W!R:6YG9G)A;65W;W)K+V%O
M<"]);G9O:VEN9T%D=FEC92YJ879A35#?2\,P$'Y>H?_#/>Q!ATL7IR#SQ2$.
M)CZI;^)#;*]MMBX7+FDW$/]WT]3*((3<=]^/NV2S-($9O-<(;Y:UJ6##ZH!'
MXCUH![;]:K2KL8#6%,C@`\\C'UQ441F!M55YKZ?2'Q4CO.@<C4/1<[)PI4D@
M[%6%0%P)%V/*,44HLO=IDB;Z8(E]I 1(-8U6)D>A3<C+T7JQ'5_$49 FV6R8
M_D&UOB:&5RK@F6KCR RXT\$"%C?SM>7Y]6*Q'. .V6DR,-T6*PBV3$6;^X"L
MBR[,+G:J4U<=2"&A%V52A@/R;K64JUL)NR&"X>ED8?JW9?RI'.*XI0JI6]/1
M/FPZ> *>/)K"P5_YW<\_>6R4<QO=! U4Z,_*B\NXX^1LZ9YQ5D;&9#3Y^/QO
M]^EN[/ZDR2]02P,$% ````@`\W%P+]->QE1D% ``CV@``!<```!);G9O:VEN
M9T%D=FEC941I9F9S+G1X=.T=:W/;QO&S/*/_<-%T:M"@P+<H45%J58E;99+8
M8SGM!\O3@<BC"(D"6 "4K*3Z[]V]]^%!@+0BJS-E8E$D[O;V=O?V#6C[Q?@V
M(9-@.B6[2[)[=T%V`W)\D:2Q/TZ/EVGT+HX^WY_$U$^CV+OR;WWB!"%,B.D8
MOKDG;T;GW]/;\],)]7OM[ODBCJ[@2G)^]N9?;V'$!8V[^^?)(@["R_,D'I]'
M\:7X.(W]&WH7Q=?G?K0XUY^2Y6(1Q>EY8_O%:3BAGT>K\=E^<?3EK^T7[T_.
MR#28TQ%I`47B*$I;&33%YQ;LH@6[R%V&7;2,P7P7K96X-V^W7\0TC0-Z"Z!(
M#&])$(6DXW7ZVR\T5\@NX\MNC!>JR+&[N[MZR%:G0WZ);DFWW>Z1;F?4Z8SZ
M!V2W#:\MOK+KNE4@]C2(SF#4[HUZ^QS$]HO7K\ENI]O<(R[\')+7K[=?D. &
MJ4& ;EZ&;A[0S3N>W 9C>E@]4'\Z#6^C:QJ?ABF-QW0!F*TUG6WIC<^$&":Z
MM2=^3Z?^<IZRY6%8+<POJ!\FWE_QYP^?$5E@<JTI4XZ@-X[":7#)(+R+DA20
M'],DJ=SR.(JI]S:>T)A.#@5C^GW&F?Y LF8+7PN#')X_F1AD=1SC0X,$^L/;
MF.^^<2C //!W>'-;K_COJP"/4:)HGI$.;KY)0MA&0\(.IL1)9T'B,8!L,!"'
M)F_#^7V#_"X0:+7(S\LD)?Y\'MV1:10CNG$T68Z1Y,DA&?OARY1<X9B$IGPS
M# Y)(T&@08\1:#!HPCFIH!!.=5(_OJ1IHG'Z&'PJ(LFK%OR WXV=FM0D1Z0.
M00XYD).YGR0&_A\_P?P5%/H+.8X6OZ;!//$`V>/Y7 ]@T!MD1$)Z1QC<C^U/
M8IGLKCG#'1Q9>! <8T--`SW&1Y?3@O\$5GV(0<9]QAKBAQ,2I3,:D^-WIPFY
M"2YG*2C$?R_!TA#<5H$X`0=_^+R($D:QL8]PG#1>,AKA?Z_P14[^<4;HYR"E
M$Q)&\0V(QCVY"](9&4<32CJ$C<+AVA+&H($'ID&4I/M:!M!<_[D;/!/7<@,W
M*+%O@^QFF3DSO[+,5V=_U.N,!AUEO@;">MDS<M9JT#.M%1QU./+P<]^R5CC7
M6P(8[SB._?N?@B0]++HJ+U2;D7<1'(GQT@13:1)W*P8J/0&$K6U'3PVU6'LE
M`_NJC>;,8_6$@EUL8)6+: '_M_"($_**H%0$Z3VYH>DLFB1DF8!>N+@'%4/)
M\=MW1(/DXU_[2Q@8D_?1A/P8S<(D"NT+/RXIJ/^0_#VB\SF-@8IX\9;&3-#_
M=#K)'-_F+5,N*(NM3@?^US)\Q>''!+0:^1-LOP:D/0UI@++=:X_ 1<Q"`H3!
M^)#%\F(>C,F8V0X)BQE/8?O:!\SV=3K-`VGZT/#ZC)2@SI/4#\<TFI*\_"@C
M#.=]&8>$N0VY,1Q2`VT0LS1O@CEPS&EX-WXZGH$MXL:471,V](%9HC(T3#%C
M*+@V"O;U=9=WI0%G/_+2I>VW_@K,<'Z@7)IO2> 'SLCQ8C&_=_)0$$-YW)Q&
MDQAX-4G&P'^QN5-V[@S.VYSF^?:U[-Y*?)ZY'5R)>[E=[)78Q5X5,=!.KARR
MU>EJ*]@^& WZH_90V<T>MYL5$#)VM#_J=DP[.D27V1TJQ[G(6/[=3V9GM-B0
M\N_=W/?,_":'%L0RFV"<ZTWMX#J3#"^]A@75GT#[GK"@S@H(34O%65&@:0F[
M<$/#E+F\8+K\%$W8A-M XH-."5A$`U[U/=?V'F=0%WR<+G'Q32IX_ >8WD+@
M0<[LD.B(102"80Y7QQC:M4A\-4/E*.<9-.?+B=^/S"O>A_>__L"C`)C)+5&9
MN#E"E3^8RS%,*^:5L,:,LQCHW:TM%BL9WP.V@<5,4/X0891 - ,=3ID'3I[=
MQ\"QR0F'Q/SMMP9P.([NF,7.R(RQE2Q"U31>'X_?UR;*EA4I<S FM5 H>_M-
M<%G<_J#9[PNA!/'_9^PO6.!GQ<@8)@9B<8IAOB&O6WQFJXZ<?$_G]!*.3WA9
M1H5)$)B2XI21J\%&*G&I!.RHX0_\+!C'Z?$8%HBD@.195D*:8D233/UY0BV$
M_@@\FN0BBN;4#S'M@AF)4ZG#J):/9'T)4X-E+D-N:^4R1;N]C8()6;%PZ:8#
MD\99A1*L6JI:5NJ+Z6JJ"9F#\X@Y,20B"0"]]B&\?8LPT-^4DTU2@6L\I^%E
M.H.1KJM\?)5]F@*4E=,_!I_XPK8FP*G:O\\K3T8B:X9>LD(?%G%4HO,E0JG9
MR[[VQC S=H008GC"P9)OP&PNYW,5C!11G _-D1:',U#?K$*(_.<_)"MKGO()
M$H/(*ANIH6?88.8K79&O=-7;@Q1>PP:[]5C$!25+,QANL/YA6P:>^_WF`,L%
M'96"D:M(#@7).TR)\LC/D?!%((5)/PFQ4*5**/3?2U!WSML+C%5XOE&2AI'=
MX2G(U8%N@Y-(K,WT)Z=>?BSWS7A$F 7#E]?B@T-S@2E*$R-B]D(I$FP?$E:9
M/FAX@A(2=NG \H7$-]PWU_#4PDH%-(FQBOI6*V')+?1^'S8*9<_\6\J..FK*
MA.7]UPA/2;(<8SEE"J?VWO.\PM#X9Y8OTHEFD8,^X]'>TP3(.C"N@<TS#8]K
M8+ZB*EI6%*U'$ R1:PRT`N5N>]09C@;[NCZZS0+E6G RX?)@-!B:X?(!"\8.
MT/O=).U\"H<)*[*%%\6L?"QMSMJV0EU@%!RQ`!6?-BV>W*C2"8?KS)+DR4SZ
M8_/859,X<C^SE%]L$*EV,KLH3N<)93 =<LN@*[DB8#9@`8H/=%@"FHR,_?$,
MP(F8?)_5&_=99*[+C89M%V;37ZVGA9=E%ASAC8*Z)FOE3K?L[TG@<_M5E$B5
M3@/S?OQZ657#%2G?H[VOC&,B?49I@4PPT@MXG'PH[WM@+N974O0E&#Q3Y7X,
M!GC<*L%YDYQGZ?91E9=<7*V^19ZS=&Y&91]D^UK:K$#2SO2UF'HWO*:3RE)A
M[L*ZJ<]BM;NIFC9GL3PAVR:XXW9!](FRJ%4SWZGZAYKRZ/5(_4DD]+VR=$@%
MPIR[*7[)RFVF^6#9KW[S@+B]8;/3X[0&D^)/86\LN_4C" )V_6#-!TQ(BGG=
MF9^0"TI9U,JKE'S6MXOO/F"^C)?WIC&%L<GR@GV$7T'E8Y%S%BT3>DWI`@\A
M?&=J3R#+M_Q5?O*P*(E9N(6H3B4012]3,HEH@JTU8/.63,?R7A;R!HNJ6+ "
MS %95^D>4A.."FR)#8G58!-*Z^7:V7;6FF00`-#^CK^XLE(4+R\.6U7;4H6(
MX'3]MJNU5;9^RYH4!G@F][K-3EOX"2!#1(=4F.^_,(H#NJ[-ZH4R,5H[U;]=
MFNG_^$EVYIA9B:-<_Y"5N>?^$F9V?_;O$5%,DGCD/672B55X[ *:3% L?<NH
M>]LRK\LT<*</RM?M8 U#IHMA@RF87(#!DA+C:"'(O8RY<QY'-TZ>"T8"0.8J
M:*:?"';%!N4N<'>+I8?M%),C2"3B>S/[D49,FSN:3KDA2? ;=1J?N-NCZ-=J
M_8&K9$'ST7D&B\$KTV LUR4C#!*DK :46SX0`V 6&^.!1ON%?D:Y(\H]M#)+
M?+L-/CID0W5Y7B<0!';<.942J2VRLR('RI$4,P6![)RG\(>%(PT^L97'45/!
M@758LI4)*[KU/;"D[5ZS.]#%C1,_#*,4Q=U*,'&;QE0Q+WW<^?=*^$EAXDVG
MQ4&3@@XUOLP5O8SSG-L-GD9.'9X("RPX*FC(.0P-11^6E&44S^=E'>G^.ZSW
MXA=0LDZ#N&0'#CWH^!D8@CDP+ <]V3&3Q#S.*$8L3T:][]TJ['9*9B?D!G05
M0_$":34!#0/&=^&C[BC*#>[(<$73%58L+:24UY2,738+E&V3R#Y'Y"EYZNWQ
M6$S%EB4LR;IIQM$VB%/<1NKD)]<GB="8%43)KE!!C;_ JY0*?&,$7L5[2S.9
MC8)"Z0.34]UBRTYS?2 "I\Q\CHUE3&3:763>NYT>./ENM]_3J7>=18 0^R;"
MW.J1SK';.G>M) /Y\Y]7-V69*JU!CH[R*FQKRU;R'L?0D278C?(7L)E_@D-"
M8:/@1'&(AG<D1BFS<<7-QA46<OQL7EL5=:[,HHX@I!KHY"=^O,I58?+D=[=R
M)H\+CM*/8HI2RWRG)Z!B+^G$T<+&F-\=HC?I=O>&VIE"]Q6$WK\Q_4-T(\V/
M$08?)::IH.0&'J.>+6S1*]MHZ^N&2U%BK(VQ1=7);*51C-5M^4A!T8W/UJ[P
M9G/+B>[XL_LDI3>>C^X6^IS&6DW2%F6/(DW5;N:W8);$A+?,6#1LLZ:J'KB]
MBD6B6IKS"+1>R#@#2F?(PU910L6[-US)'GVR\T>T2MTC.W ^H(/'V3JYW,E2
MPS@K>*H0CVR!"2C!@JF.#VRBE!J=)W2Y@&K-R*:&_CRK(<UZ9*_=9E%Y?]CL
MJT[8(DG,8)35`:94VK72XHE:1(FE9!D_F)Z:1]$U*W#AB>3$8I=R3"I.$]>R
MSS48YF[ L)+$=89Y4L,9I[2U)@?S]=_R`V+9BGJ'@_'A9$;'UZ9*O*# %4K&
MJ&AY#'N?8I8?QI"(UYN!\BG=5G'29J(D&?1-J01Y0:+ES&+7*G>(%^]?[H!7
M7@[9\MU?D@#+&:D*UW$@N\4*OP0?BO76!Z&XKMB_8[)92/86*=J3E)'"[H;R
M$Z2V3"K]8LY^8S'R,4N!W!"^^T\0O+ARF:VM'4Q<,6KHA)4BRIID319T'$P#
M3CR3<@*$(B Q#!G[74KGZ93<47!=65Z%U9_@(S &7-QKRE0'D]-'$<8U])HK
MC_8ZBNQY**^Z"JN&FLJWU BC7Z&L,DKJ]XQQSD3#&<//QC/3UNE@'K%WL*_O
M\5CIP.<;5[2;)5!DZ*VZWT.[79N4)+,+%8:,#8O"PO[+X*PR/['S:W@=1G?R
MA)'T?I$[M84)C)=&AH*1=S!$SZ$/GD-'W6"K;EZUA1%EM-W@V&7Z:TK<C0(@
MQF&TW 4$FA<#'9\6WJ1BP;^4F2SIQ)4=2]C&32#VD6G)<K6"*D^@%:\J#W-F
M.2G^<E&W8%$[.B(%U)7<&O+\7'_8:_8&*OP5P]M\[\B#<;0,4\:'9\J;0).(
MR2DX`<=)$ER&_L6<LOQW"?<,R6Y('KHNV^_AES.O&JUB]F:P<C-8E3%8#E A
M4D$)8QJ 3K;RI!D4K*U*)62.-S:E,Z?NFKJ84<@"Y*RX;RR?'3'-Z?KZNV3U
M,OV]TH.OC4FA<L]C42\[9*Z:;P3)F5D>+^LB%%L&G*.[&55*'PNKW"^:>(_:
M0O)&W+#^-9I'S+6?:=M(#L_R5I&]DE:1O:+-JB81\VNK/:33'PT.1H.!:@\!
M^*H]Q)YE-X9TVJ-NU[[U;0_O?!MF;WS;I%>C7C_"L;A_%T5]DP:V;:,)8:^-
M2>"]CFI"R.3U,'*%-]$W#4>1$4@T?"^LVU%7EZ! 59NTY7/E!YYS,Z_S8RY,
MICG6?@*'C8$PBX7#A?8PT3*L7&$Z8&6=P@"4O2]7:*@L&F*B4&O<1=(&S!JM
MZ&PF-QY?+6%_R==436K]_P'UI' M5U'[)2IJOVS3636E+JU65?MY567,S*FK
MWI[5Q[;'^MCV9 SX))UEM1]Y4>-A$26M8Y4/X,A$^36F/%HGV!<_!0JG"DYO
M.N_XSH\13]9X+/K/NV;MQVX28FUKLGC#*8:A;V(T#)BNM:SUX(.*,L44-=IT
MPK )"=,_(8,I&M0"/>^.OHQ%^Q+@X6%:*XST``$E2,AE<$O#)O')R=]^.OVK
M2BOQ)C+1$'<7S.>8E>2-:1//W*]=O=)"PM-7-AGP.T8$G2?&A%VJ>"KN??PE
M2M] .#+)5U:(N('.JHH55YS80D;5J23V+!QOEQ_T2A\#?%84#\>FG*&.#4"D
MZWC#*W\<5GM?2XF=3+$W[^R<^,*,\5JZ7G>$&5-BXX$M(, _G_/([O;(W-BI
M?C4M-HL^"\2MFI+N1I1TMXK7K$U3!*#+!^G+Q,J>;ZO ^9O\`IF\/A_[!9PH
MV$(!.V0N+5^9'+ 4EXL5RNZ^F>K"!BTS\C,B/IXWS.80<(+BO-E:H,+)+,@2
M"U#<8K)!_PVNU\Q2R&@QL1*,10CF&Z7,!'5V=#[Y+ ;7ZI4I6*L:?Q$Z6RG2
MXL723$ZB=$$KS9M/P&)=`@6>E8Q4WR^QHP3/'NL3-&6\A(']&>*XL ?D$3]&
M_0JG2$_Z\/;[MV0&!V(2H06 Q3&_']-I3),9G?!Q//8W'[!'@D#L.G_-D5O;
MK4\A<8L_E^1U9]7C>A"LX"^G1D7Q:X[WEL]9JGO$R?Q2J@5>A[K!QR2"Q43#
MC/EPSO9W!N,,,AFZVTS/B;C&5P[2YF',$]SE^5,T]N=G6*:=P] S^ >D>JI8
MB5Y=G/L,1R-0JH_1LXF>8!\MOH]6?>S+XZFR)^'VUZ(-!EGUQV]UVM8C<MN]
M45<_*TD\(7<=<)EPK#OJ]\UPC$5C>S)[M/#'U_YE\4T*0%R/$U>XT[6C%Q.S
MPW7"GLV?>#L5`8A!#X&U\B(&F#-S!T8QTO!HA(HZCB^76% WE-?%,@E"(()2
M?O(&F7NEM1)VAT,]+MF.IWF5+*9%>2GM8'XBO_,:2!ZE!V$U%M-L_@DG" NQ
M\K*\*'1^N37 &<T2/(QGK[(!W"4\@IW]D1DF[G2]IS=12I^51ET;L>>H6-?>
MQ";Z=0-*Z:?0K3&MEK;=`&I&Z?8`\/^5[I,HW768]7_=^^S=8N-!W4^ENE.]
MY+D1'AIZO JI9Z.VC:VTC*VTJC:P28FAFBBHH:M&%3QB6Y8/=.&A&DA.__8L
MI[?D7OHU=&,V@J[0CS:4?*2_UO0GU>R5%>"-S4+M>:=AD ;^//@-QHC)C(G#
M/78+26<XQ(>H2W/RH%3Z]NKZK<JQ%*9>C"9-^803U4O'P.GDA_6'(*RE[#RR
M)!KJ7_O/(!0LALD,51LVLD7&[Z5I(Q,<MR>\7!ZH%;_D;S:8T O_=$.6VI5F
MS-A4R5]NL"V8"?^Q;-E_`5!+`0(4`!0````(`(T$<"\0KWFS(P0```0.``!I
M``````````$`( "V@0````!$978O261E83,P,B]P<F]J96-T<R]31E]/8W1O
M8F5R,C@O<W!R:6YG+W-R8R]O<F<O<W!R:6YG9G)A;65W;W)K+V%O<"]F<F%M
M97=O<FLO1&5F875L=$EN=F]K:6YG061V:6-E+FIA=F%02P$"% `4````" !Q
MJ6\OA/QX</,0```Z1P``9@`````````!`" `MH&J! ``1&5V+TED96$S,#(O
M<')O:F5C=',O4T9?3V-T;V)E<C(X+W-P<FEN9R]S<F,O;W)G+W-P<FEN9V9R
M86UE=V]R:R]A;W O9G)A;65W;W)K+U!R;WAY0V]N9FEG4W5P<&]R="YJ879A
M4$L!`A0`% ````@`<:EO+W>C>RYG$ ``E38``&0``````````0`@`+:!(18`
M`$1E=B])9&5A,S R+W!R;VIE8W1S+U-&7T]C=&]B97(R."]S<')I;F<O<W)C
M+V]R9R]S<')I;F=F<F%M97=O<FLO86]P+V9R86UE=V]R:R]0<F]X>49A8W1O
M<GE"96%N+FIA=F%02P$"% `4````" "-!' O.-^&)?4#```7#P``= ``````
M```!`" `MH$*)P``1&5V+TED96$S,#(O<')O:F5C=',O4T9?3V-T;V)E<C(X
M+W-P<FEN9R]S<F,O;W)G+W-P<FEN9V9R86UE=V]R:R]A;W O9G)A;65W;W)K
M+W-U<'!O<G0O4VEM<&QE26YT<F]D=6-T:6]N061V:6-E+FIA=F%02P$"% `4
M````" !QJ6\O,2&X%BX!``#C`0``6 `````````!`" `MH&1*P``1&5V+TED
M96$S,#(O<')O:F5C=',O4T9?3V-T;V)E<C(X+W-P<FEN9R]S<F,O;W)G+W-P
M<FEN9V9R86UE=V]R:R]A;W O26YV;VMI;F=!9'9I8V4N:F%V85!+`0(4`!0`
M```(`/-Q<"_37L949!0``(]H```7``````````$`( "V@34M``!);G9O:VEN
F9T%D=FEC941I9F9S+G1X=%!+!08`````!@`&`"H#``#.00``````
`
end

[Springframework-developer] Is it worth keeping BCEL around at all?

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

You may not know this, but ASM has switched from an LGPL to BSD license. 
Given that BCEL is so big and bloated (BCEL is 20 times larger, 500k vs 
25k), and runs a lot slower to boot, is it really worth using BCEL in 
any fashion any longer?

Hibernate runs a lot faster with cglib-asm than cglib with BCEL. I think 
cglib 2 won't even offer the option of using BCEL...

The only direct dependency we seem to have on BCEL right now is 
BcelAttributes and BcelAttributeWriter.

What does everybody think?

[Springframework-developer] More Spring in the news

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

Ted Neward is mentioning Spring in a conference presentation...

http://www.nofluffjuststuff.com/2003-08-detroit/local/agenda.pdf

I think it's significant that the word seems to have spread beyond the
Spring team now sufficiently for others to raise it in public.

[Springframework-developer] Spring makes it to the Struts news page

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

http://jakarta.apache.org/struts/news/

I'm sure some of you have already seen this link.

Regards,
Rod

[Springframework-developer] AOP API Finalization

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

I've now committed all changes discussed. I'm pretty happy with the new API
now. It will enable us to expand our AOP coverage to pre/post advice and
beyond interception in future without breaking the existing API.

I want to continue to do some internal refactoring and optimization, but
that won't affect Spring users.

To M3 and beyond!

Regards,
Rod

Re: [Springframework-developer] Checkstyle

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

Kopylenko, Dmitry wrote:
> Hello everyone.
> 
> I could see checkstyle.xml in our CVS tree, but do we have the actual 
> tool (checkstyle.jar)? I couldn't find it.
> 

It's part of the Maven build. I haven't updated it in a while. The 
checkstyle file hasn't been configured to a particular Spring coding 
standard either (if such a thing exists).

I've been meaning to check that the build still works so I'll do that 
just now.

Luke.

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

Re: Fw: [Springframework-developer] Revised AOP API proposal

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

Yanger,

Yes, Spring supports introductions, which are normally used for mixins.
Introductions are definitely useful for "power users" of AOP. And they can
potentially be added behind the scenes. For example, I'm experimenting with
a "Modifiable" attribute that adds a Modifiable interface(isModified() etc)
via a mixin. Could be useful for caching and doesn't require the application
developer to work directly with introductions or mixins.

Regards,
Rod

----- Original Message ----- 
From: "Yanger" <yan...@ya...>
To: "springframework-developer@lists."
<spr...@li...>
Sent: Saturday, November 15, 2003 2:58 PM
Subject: Re: Fw: [Springframework-developer] Revised AOP API proposal


> Besides advice, introduction (from my perspective, it is some kind of
mixin, right?) seem to be another important concept of AOP. Have you
implemented it in Spring? I think that introductions maybe too geek to use
in practice, do you think so?
>
> Best Regards,
> Yanger
> yan...@ya...
> 2003-11-15 22:58:13
>
> ======= 2003-11-12 01:03:14 Your mail is：=======
>
> >Forwarded on behalf of Bob...
> >
> >
> >
> >renaud wrote:
> >
> >>certain join points and values at those points. Advice defines code that
is
> >>executed when a pointcut is reached. These are, then, the dynamic parts
of
> >>AspectJ.
> >></AspectJDoc>
> >>
> >>By reading this, you can really think that the advice and the pointcut
are
> >>orthogonal and defined independently. Indeed, it seems not flexible at
all
> >>to define at the same place the code to be executed and where it is
> >>executed.
> >>
> >>
> >I think it means that advice maps code to pointcuts.
> >
> >>To me it is confusing. Moreover, lots of work on AOP have pointed out
the
> >>benefits of having independent structures for the both. To me AspectJ
> >misses
> >>something here: the ability to define independent (unlocated) advice -- 
> >like
> >>an interceptor does.
> >>
> >>
> >You can map to an abstract pointcut.
> >
> >I think Advice is the correct term here.
> >
> >Thanks,
> >Bob
> >
> >
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email sponsored by: ApacheCon 2003,
> >16-19 November in Las Vegas. Learn firsthand the latest
> >developments in Apache, PHP, Perl, XML, Java, MySQL,
> >WebDAV, and more! http://www.apachecon.com/
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >.
>
> = = = = = = = = = = = = = = = = = = = =
>
>
> NHS甸u肌:瑞?瑞藏}wyq胧|y叮 z)rHN即
Zzο?② 糅MM{z并y箔

Re: RE: [Springframework-developer] Type 3 IoC support

[Yanger <yan...@ya...>]

I feel the artical is very well. 

Introduction to IoC 
See IoC example on why to use IoC with an example in Pico. Changes to this example to use it with Spring are in Spring example. 

Example for conventional lookup (e.g. with JNDI in EJBs): 

public class Foo { 
public Foo() { 
} public String service() { 
return BarManager.lookup("myBar").doSomething(); 
} 
} 
Example of IoC 3: 

public class Foo { 
private Bar bar; public Foo(Bar bar) { 
this.bar = bar; 
} public String service() { 
return bar.doSomething(); 
} 
} 

Types 
Method-based (M) IoC : Pass dependent components to the component with every method call 
Interface-based (I) IoC (Type 1): Uses Interfaces like Serviceable, Configurable etc. for declaring dependencies 
Setter-based (S) IoC (Type 2): Uses setters for setting dependent components 
Constructor-based (C) IoC (Type 3): Uses constructors for declaring dependencies 
Example Method based IoC : 

public class Foo { 
public Foo() { 
} public String service(Bar bar) { 
return bar.doSomething(); 
} 
} 
Example of IoC 1: 

public class Foo implements Barable { 
public Foo() { 
} public void doBar(BarManager bm) { 
Bar bar = (Bar) bm.lookup("myBar"); 
bar.service(); 
} 
} 
Example of IoC 2: 

public class Foo { 
private Bar bar; public Foo() { 
} public void setBar(Bar bar) { 
this.bar=bar; 
} public String service() { 
return bar.doSomething(); 
} 
} 

Disadvantages 
You declare your dependencies, some magic happens and they are resolved. Magic makes source code harder to understand than lookups (because they are implicit not explicit) 

Advantages 
If you use singletons or lookups your unit tests are difficult to write (Just see all those special J2EE unit frameworks). With lookups you usually have to implement a registry that supplies MockObjects. If your lookups are static methods replacing them with MockObjects is even more difficult. With lookups you might have to do this (if you can control the registry, which most of the time is impossible or at least hard to do): 
// What if you can't change the created class 
// in your singleton or registry? Do you need to rewrite 
// the whole JNDI lookup classes? 
BarManager.setBarClass("myBar", MockBar.class);Foo foo = new Foo(); 
assertEquals("ping", foo.service()); 
IoC is more JUnit test friendly than lookups. With Type-3 IoC you just do: 

Foo foo = new Foo(new MockBar()); 
assertEquals("ping", foo.service()); 
With Type-2 this would be: 

Foo foo = new Foo(); 
foo.setBar(new MockBar()); 
assertEquals("ping", foo.service()); 
No external dependecies. You can develop and test your components in the enviroment you like, you do not need to use a special deployment enviroment for your components during development (like with JNDI / EJB) 
Easier to reuse and easy exchangeable between different IoC containers. Either implement simple wrappers or add setters and interfaces to use components from e.g. Pico in Avalon and Spring 

Advantages of Type-2 
Beans are well understood by Java developers, beans exist in most projects 
More easily satisfies optional dependencies 

Disadvantages of Type-2 
Dependencies can be seen from the code. What are dependencies and what are normal setters and getters? Additional setters and getters make code more noisy 
Needs some XML (or other) meta data which makes understanding code more difficult from looking at it 

Advantages of Type-3 
Stronger contract between components 
Components cannot exist in "limbo" state between creation and when they can be used. This is more defensive 

Disadvantages of Type-3 
You may need your constructors (I do not :-) 
Inheritance can become more difficult.

Re: Fw: [Springframework-developer] Revised AOP API proposal

[Yanger <yan...@ya...>]

QmVzaWRlcyBhZHZpY2UsIGludHJvZHVjdGlvbiAoZnJvbSBteSBwZXJzcGVjdGl2ZSwgaXQgaXMg
c29tZSBraW5kIG9mIG1peGluLCByaWdodD8pIHNlZW0gdG8gYmUgYW5vdGhlciBpbXBvcnRhbnQg
Y29uY2VwdCBvZiBBT1AuIEhhdmUgeW91IGltcGxlbWVudGVkIGl0IGluIFNwcmluZz8gSSB0aGlu
ayB0aGF0IGludHJvZHVjdGlvbnMgbWF5YmUgdG9vIGdlZWsgdG8gdXNlIGluIHByYWN0aWNlLCBk
byB5b3UgdGhpbmsgc28/CQkJDQoNCkJlc3QgUmVnYXJkcywNCllhbmdlcg0KeWFuZ2VyMTk5N0B5
YWhvby5jb20uY24NCgkJCQkJCQkyMDAzLTExLTE1IDIyOjU4OjEzDQoNCj09PT09PT0gMjAwMy0x
MS0xMiAwMTowMzoxNCBZb3VyIG1haWwgaXOjuj09PT09PT0NCg0KPkZvcndhcmRlZCBvbiBiZWhh
bGYgb2YgQm9iLi4uDQo+DQo+DQo+DQo+cmVuYXVkIHdyb3RlOg0KPg0KPj5jZXJ0YWluIGpvaW4g
cG9pbnRzIGFuZCB2YWx1ZXMgYXQgdGhvc2UgcG9pbnRzLiBBZHZpY2UgZGVmaW5lcyBjb2RlIHRo
YXQgaXMNCj4+ZXhlY3V0ZWQgd2hlbiBhIHBvaW50Y3V0IGlzIHJlYWNoZWQuIFRoZXNlIGFyZSwg
dGhlbiwgdGhlIGR5bmFtaWMgcGFydHMgb2YNCj4+QXNwZWN0Si4NCj4+PC9Bc3BlY3RKRG9jPg0K
Pj4NCj4+QnkgcmVhZGluZyB0aGlzLCB5b3UgY2FuIHJlYWxseSB0aGluayB0aGF0IHRoZSBhZHZp
Y2UgYW5kIHRoZSBwb2ludGN1dCBhcmUNCj4+b3J0aG9nb25hbCBhbmQgZGVmaW5lZCBpbmRlcGVu
ZGVudGx5LiBJbmRlZWQsIGl0IHNlZW1zIG5vdCBmbGV4aWJsZSBhdCBhbGwNCj4+dG8gZGVmaW5l
IGF0IHRoZSBzYW1lIHBsYWNlIHRoZSBjb2RlIHRvIGJlIGV4ZWN1dGVkIGFuZCB3aGVyZSBpdCBp
cw0KPj5leGVjdXRlZC4NCj4+DQo+Pg0KPkkgdGhpbmsgaXQgbWVhbnMgdGhhdCBhZHZpY2UgbWFw
cyBjb2RlIHRvIHBvaW50Y3V0cy4NCj4NCj4+VG8gbWUgaXQgaXMgY29uZnVzaW5nLiBNb3Jlb3Zl
ciwgbG90cyBvZiB3b3JrIG9uIEFPUCBoYXZlIHBvaW50ZWQgb3V0IHRoZQ0KPj5iZW5lZml0cyBv
ZiBoYXZpbmcgaW5kZXBlbmRlbnQgc3RydWN0dXJlcyBmb3IgdGhlIGJvdGguIFRvIG1lIEFzcGVj
dEoNCj5taXNzZXMNCj4+c29tZXRoaW5nIGhlcmU6IHRoZSBhYmlsaXR5IHRvIGRlZmluZSBpbmRl
cGVuZGVudCAodW5sb2NhdGVkKSBhZHZpY2UgLS0gDQo+bGlrZQ0KPj5hbiBpbnRlcmNlcHRvciBk
b2VzLg0KPj4NCj4+DQo+WW91IGNhbiBtYXAgdG8gYW4gYWJzdHJhY3QgcG9pbnRjdXQuDQo+DQo+
SSB0aGluayBBZHZpY2UgaXMgdGhlIGNvcnJlY3QgdGVybSBoZXJlLg0KPg0KPlRoYW5rcywNCj5C
b2INCj4NCj4NCj4NCj4NCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQo+VGhpcyBTRi5OZXQgZW1haWwgc3BvbnNvcmVkIGJ5OiBBcGFj
aGVDb24gMjAwMywNCj4xNi0xOSBOb3ZlbWJlciBpbiBMYXMgVmVnYXMuIExlYXJuIGZpcnN0aGFu
ZCB0aGUgbGF0ZXN0DQo+ZGV2ZWxvcG1lbnRzIGluIEFwYWNoZSwgUEhQLCBQZXJsLCBYTUwsIEph
dmEsIE15U1FMLA0KPldlYkRBViwgYW5kIG1vcmUhIGh0dHA6Ly93d3cuYXBhY2hlY29uLmNvbS8N
Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPlNwcmlu
Z2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQo+U3ByaW5nZnJhbWV3b3JrLWRldmVs
b3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj5odHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5l
dC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQo+Lg0KDQo9ID0gPSA9
ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0NCg0KDQo=