springframework-developer — Spring Framework developers list

[Springframework-developer] DTD change

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

All,

I've changed the DTD to accommodate lists (even including runtime references
via the <ref> element) within <map> entries. This change is backward
compatible. I've refactored AbstractBeanFactory by extracting several
methods to make runtime reference resolution more maintainable.

See collections.xml in the XML bean factory tests for an example of a map
containing a list.

Regards,
Rod

____________________________________________________
Rod Johnson
J2EE Consultant and Author
+44 7973 409 132
rod...@in...

Author of "Expert One-on-One J2EE Design and Development"
(October 2002).
http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/

Founder, Spring Framework:
http://www.springframework.org

Re: [Springframework-developer] Maven Build...

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

Luke,

This is looking really good. Thanks. I might give Maven another try myself.

Guys, we should try to put the report somewhere. The source xreference is
particularly nice.

Regards,
Rod

----- Original Message -----
From: "Luke Taylor" <ne...@fr...>
To: <spr...@li...>
Sent: Tuesday, July 15, 2003 12:19 AM
Subject: [Springframework-developer] Maven Build...


> Hi all,
>
> I've updated the Maven build files to bring them into line with the
> current code. The output from "maven site" is here:
>
> http://monkeymachine.ath.cx/spring/maven-reports.html
>
> The clover report ("maven clover") is here:
>
> http://monkeymachine.ath.cx/spring/clover
>
> "maven dist" should build a set of jars which match the current build.
>
> It should work with maven-b10 which was released today - though I've
> been using a cvs version and haven't actually tried the release.
> As before, some of the repository items will need to be added by hand
> but that's relatively straightforward. You can copy them from the
> current build into MAVEN_HOME/repository.
>
> I hope to add some more stuff in the coming weeks, e.g.
>
> o Jalopy integration and updated checkstyle file.
> o stylesheets more closely matched to the current spring site.
> o subprojects for the samples.
>
> Luke.
>
>
> --
>   Luke Taylor.                      Monkey Machine Ltd.
>   PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] Maven Build...

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

Hi all,

I've updated the Maven build files to bring them into line with the 
current code. The output from "maven site" is here:

http://monkeymachine.ath.cx/spring/maven-reports.html

The clover report ("maven clover") is here:

http://monkeymachine.ath.cx/spring/clover

"maven dist" should build a set of jars which match the current build.

It should work with maven-b10 which was released today - though I've 
been using a cvs version and haven't actually tried the release.
As before, some of the repository items will need to be added by hand 
but that's relatively straightforward. You can copy them from the 
current build into MAVEN_HOME/repository.

I hope to add some more stuff in the coming weeks, e.g.

o Jalopy integration and updated checkstyle file.
o stylesheets more closely matched to the current spring site.
o subprojects for the samples.

Luke.


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

Re: [Springframework-developer] Can't build tests...

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

Sorry. Problem solved by a clean checkout... cvs update not working 
properly as usual.

Luke.


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

RE: [Springframework-developer] Can't build tests...

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

I would think you'd need to re-synchronize.

Dmitriy.

-----Original Message-----
From: Luke Taylor [mailto:ne...@fr...] 
Sent: Monday, July 14, 2003 1:18 PM
To: spr...@li...
Subject: [Springframework-developer] Can't build tests...


Anyone else seeing this?

buildtests:
     [mkdir] Created dir: F:\cvs\springframework\main\.testclasses
     [javac] Compiling 121 source files to 
F:\cvs\springframework\main\.testclasses
     [javac] 
F:\cvs\springframework\main\test\com\interface21\jndi\SimpleNamingContextTes
ts.java:19:
package com.interface21.jndi.support does not exist
     [javac] import com.interface21.jndi.support.SimpleNamingContextBuilder;
     [javac]                                     ^
     [javac] 
F:\cvs\springframework\main\test\com\interface21\jndi\SimpleNamingContextTes
ts.java:20:
package com.interface21.jndi.support does not exist
     [javac] import com.interface21.jndi.support.SimpleNamingContext;
     [javac]                                     ^


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





-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Can't build tests...

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

Anyone else seeing this?

buildtests:
     [mkdir] Created dir: F:\cvs\springframework\main\.testclasses
     [javac] Compiling 121 source files to 
F:\cvs\springframework\main\.testclasses
     [javac] 
F:\cvs\springframework\main\test\com\interface21\jndi\SimpleNamingContextTests.java:19:
package com.interface21.jndi.support does not exist
     [javac] import com.interface21.jndi.support.SimpleNamingContextBuilder;
     [javac]                                     ^
     [javac] 
F:\cvs\springframework\main\test\com\interface21\jndi\SimpleNamingContextTests.java:20:
package com.interface21.jndi.support does not exist
     [javac] import com.interface21.jndi.support.SimpleNamingContext;
     [javac]                                     ^


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

RE: [Springframework-developer] PathMatchingUrlHandlerMapping

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

Ok, done...

Changes as follows:

*** Addition of com.interface21.util.PathMatcher with corresponding
tests
Maybe documentation could be a bit more extensive, I've added __some__
examples of what patterns match with what.

*** Addition of
com.interface21.web.servlet.mvc.multiaction.PathMatchinMethodNameResolve
r
This class extends PropertiesMethodNameResolver in the usual fashion,
just overriding the getMethodName-method. I noticed one thing while
writing the tests (included in MultiActionControllerTestSuite or
whatever its name is, in the com.interface21.web.servlet.mvc package).
The PropertiesMethodNameResolver implements InitializingBean, but the
afterPropertiesSet() method does not get called during the tests. When
the not-empty-constructor is used, the afterPropertiesSet() method is
called directortly from there, but that shouldn't be the case, should
it... Anyway, I've implemented a test in the
MultiActionControllerTestSuite that tests with an empty constructor as
well, but can't enable it because it fails because afterPropertiesSet()
isn't called. Is this only called at runtime or something?

*** Changes in
com.interface21.web.servlet.mvc.multiaction.PropertiesMethodNameResolver
Same thing as with the AbstractUrlHandlerMapping, I made the mappings
Properties object protected so I can access it from any extending
classes

That's basically it...

Please keep me posted on when you guys have committed it, so I can keep
in sync with the codeline...

Cheers,

Alef

[Springframework-developer] RealMethods

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

F.Y.I.

There is a "J2EE framework" called RealMethods I've been following the
progress for a while. It used to be a "closed source" and now it's an "open
source". It claims that it implements all the "Core J2EE design patterns"
https://sourceforge.net/projects/realmethods/
<https://sourceforge.net/projects/realmethods/> 

Regards,
Dmitriy.

Re: [Springframework-developer] JavaBeans lifecycle considerations?

[Ivan R. <iv...@we...>]

Juergen & Rob,

Thank you for your thoughtful replies. I will try to answer all
your questions hopefully not missing anything :)


> * Beans that want to can execute on their own thread
> 
> How is this supposed to work? The execution thread is  always
> determined by the caller of a bean's methods. In that respect,
> a bean can't execute "on its own thread", if I understand correctly.
> A bean can *create* its own threads though, either on initialization
> or on certain method calls. But in any case, the main method invocation
> will always execute in the caller's thread. Therefore I don't think that
> we need "own thread" support. Spring simply treats such thread starters
> as conventional beans, initializing them and making them available. It
> doesn't care if and when a bean starts and stops new threads - that's
> the bean's responsibility.

   There are two ways to do this. One is to call the onStart method
   on a separate thread and just let it run. When I was writing my email
   I was thinking about something like that but after reading your email
   I don't like that approach anymore. I agree that it should be a bean's
   responsibility to do whatever it needs to do, including starting its
   own thread of execution (and stopping it on onStop).


> * Bean pools (check-in, check-out)
> 
> As you've noted, Spring already supports the first two notions. Regarding
> bean pools, I'm not too convinced if they actually add value.
> In contrast to EJBs, beans are extremely lightweight, the on-demand
> creation overhead normally doesn't matter.

   I agree in general, but there are some cases when pooling is necessary.
   We all use it for database access. I need it for threads (can't think
   of anything else). Bean pools can be realised in a non-intrusive manner.
   For example, a bean pool can consist of a single interface provided
   facilities to create beans on-demand exist.


> Instance pooling would add a significant amount of overhead: There
> would indeed have to be an explicit checkout and check in, or a
> transparent checkout / check in on each method invocation, using an
> invocation proxy that delegates to the actual pooled instance. That
> may make sense for access to load-balanced remote services, but I

   I would go for the explicit check in/checkout. That is one more
   interface for a bean to support, but only if it wants to. I think
   this is consistent with Spring philosophy. And no changes to the
   rest of the framework would be required.


> * Load/unload beans
>  
> I guess you mean bean instances here, not bean classes

   Right, bean instances.


> and I assume load / unload means invoking initialize / dispose
> of predefined bean instances. I wonder what use cases you see for
> explicit beanFactory.load("myBeanName") and beanFactory.unload("myBeanName")
> calls. When would an application developer want to explicitly load
> and unload beans at runtime - maybe to make certain exported remote
> services available / unavailable?

   Exactly. For example:

   1. If there is a bean that performs certain services for other beans
      and it depends on some external resources. If those services
      become unavailable I need to manually replace the bean with something
      else. Or, I might need to load another bean pointing to a backup
      resource on the network (I might have restored the database from the
      dump, for example).

   2. My server consists from a series of plugins/services, and at any
      time I can load the ones I need. Sometimes I need something to
      happen at which time I can load the plugin. The plugin then registers
      a listener and starts to respond to application events (or it changes
      the application workflow somehow).

   3. It is needed for the bean pool :)


> * Persist bean configuration (not serialization, properties only)
>  
> Why would you want to persist a bean's property values - when would
> you want to load them again? Basically, the bean factory defines all
> property values, e.g. in a properties or XML file. Changing values at
> runtime should also occur via these files IMO, the modified file timestamp
> triggering a reconfiguration of the watching factory.

   You certainly don't want automatic reconfiguration as you won't
   be able to guarantee consistency. How would I be able to change the
   configuration programatically? Your approach would force me to understand
   how each factory stores configuration and I am not interested in that.

   I would like to be able to change a parameter and keep the parameter
   the next time application wakes up. This is probably a job for JMX
   (I'll mention it in my next email).

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [Springframework-developer] JavaBeans lifecycle considerations?

[Ivan R. <iv...@we...>]

> You mean a bean that kicks off an asynchronous process somehow? But what
> would it return to the caller? We probably do need more sophisticated thread
> models for app context event listeners. At present the multicast event
> listener uses the same thread as the call that created the event, allowing a
> rogue listener to lock the app. It would be easy to support several options,
> with this the default, as it's low overhead if people implement their
> listeners properly. (Ie a listener kicks off a background thread if it needs
> to).

   It sounds like something the framework needs, although I did not have a
   need for such functionality in my projects.


> This is a very interesting area. Semi-coherent braindump follows.
> 
> Do we want to call additional setters on a running bean? e.g.
> setRetryCount(n) to a new value? This might be appropriate in some cases,
> especially for simpler things. Yet it would place constraints on beans,
> implying that some metadata might be required to indicate which fields were
> refreshable.

   Metadata sounds too complex. I would go for a black&white approach.
   Either a bean is reconfigurable or not. Reconfiguration makes sense the
   most with service beans and I guess that those would be the ones that would
   expose themselves as reconfigurable.

   I have a fear that we can build this but that it would become too
   complex. The only simple solutions is the one when you explicitly
   check beans in and out, and there you can treat one cycle as a
   transaction. Idle beans are obviously safe to reconfigure.

   Or can we confine ourselves to only reconfigure service beans. For
   example: call stop, reconfigure, call start (or do it transparently,
   which is probably easier).


>>* Reload bean class (in combination with bean pools this probably means
> 
> that multiple bean versions will run in parallel at times)
> 
>>We would need own classloader hierarchies for such stuff. Basically, every
> 
> bean instance would have to be loaded in its own classloader to achieve
> this. I rather consider classloader handling an issue for J2EE containers,
> not for application frameworks, due to all the nasty hassles that are
> involved. And as I've outlined above, this is really hard if not impossible
> to handle properly in a concurrent environment, as any bean can have
> dependencies on any other. How to guarantee consistency within the whole
> system here?
> 
> I don't want to get into class loading, if we can possibly help it.

   OK, let's forget about that for the moment. I am not too keen either.



>>* Persist bean configuration (not serialization, properties only)
> 
> Isn't the XML doing this?

   What do you mean?


>>* Finally, a container needs to be written which would allow access to all
> 
> beans and their configuration from the outside, plus options to load/unload
> beans, reconfigure them, inspect them and so on.
> 
>>Basically, a Spring BeanFactory resp. ApplicationContext matches that
> 
> role, although these interfaces represent a bean user API, avoiding bean
> definition details. Implementation classes like AbstractBeanFactory,
> ListableBeanFactoryImpl, and AbstractApplicationContext offer access to such
> SPI details too. With some added methods e.g. for loading/unloading,
> sufficient control and inspection capabilities should be available.
> 
> What about JMX? So long as it could be done without forcing JMX complexity
> on user code.

   Now, JMX is a very interested technology. I did not want to mention
   it before to avoid getting lost in discussion and because I am still
   investingating it.

   From what I've seen so far it should be possible to add a JMX layer
   to Spring and transparently expose JavaBeans that form the application.
   Not all beans should be exposed, we could mark the ones we want in
   the configuration somehow.

   Most of the features I have mentioned here have their place in JMX
   and some of them would be required in order to fully support it. But
   I am still playing with the spec. and the reference implementation,
   and I haven't formed my final opinion about it.

   But even know it is obvious that JMX fits naturally to the existing
   Spring functionality.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

RE: [Springframework-developer] PathMatchingUrlHandlerMapping

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

Ok, I placed the PathMatcher in web.util, but you're right, I'll
refactor it into the general util package. I'll send the zip again when
it's finished...

Alef


-----Oorspronkelijk bericht-----
Van: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Verzonden: Monday, July 14, 2003 4:07 PM
Aan: Rod Johnson; al...@jt...;
spr...@li...
Onderwerp: RE: [Springframework-developer] PathMatchingUrlHandlerMapping


Alef,

I've just browsed your code, and already intended to suggest to refactor
the path matching stuff into a com.interface21.util.PathMatcher or the
like, as it doesn't depend on handler mappings or even servlet classes.
So fine, go ahead! I really welcome more flexible path resolution
options. Guess why SimpleUrlHandlerMapping is called "simple"... ;-)

Regarding unified configuration: I actually gave some thoughts to this,
but didn't reach any conclusion. The role of a HandlerMapping is to
resolve a handler (i.e. Controller), while the role of a
MethodNameResolver is to resolve a method within a certain handler (i.e.
MultiActionController). As the latter can also work via explicit
"action" parameter etc, I don't think we should mix these roles.

I added a "...*" mapping to AbstractUrlHandlerMapping (thus both
BeanNameUrlHandlerMapping SimpleUrlHandlerMapping) some weeks ago,
mainly to enable a single "/mymulti/*" mappings to a
MultiActionController that can map sub paths like "/mymulti/myactionX"
to its methods then. Previously, one had to repeat all those
method-level mappings one-by-one on the HandlerMapping.

Of course, it makes sense to have similar path matching options on both!

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Monday, July 14, 2003 3:49 PM
To: al...@jt...; spr...@li...
Cc: j=FCrgen h=F6ller [werk3AT]
Subject: Re: [Springframework-developer] PathMatchingUrlHandlerMapping


It certainly would be handy for method name resolution. We need
consistency between these two things. Juergen, did you give any thought
to having one config handle both by default somehow?

Regards,
Rod

----- Original Message -----
From: "Alef Arendsen (JTeam)" <al...@jt...>
To: "'Rod Johnson'" <rod...@in...>;
<spr...@li...>
Sent: Monday, July 14, 2003 2:50 PM
Subject: RE: [Springframework-developer] PathMatchingUrlHandlerMapping


> Wait!!!  ;-)
>
> Right now I'm noticing that this functionality would also be verrrry=20
> handy for the methodname resolver...
>
> So I'll have to abstract the PathMatching stuff into a separate class=20
> (which makes testing even easier probably) and extend (probably) the=20
> PropertiesMethodNameResolver thingy as well...
>
> So if no objections here, I'll go ahead and do that as wel...
>
> Alef
>
>
> -----Oorspronkelijk bericht-----
> Van: Rod Johnson [mailto:rod...@in...]
> Verzonden: Monday, July 14, 2003 3:37 PM
> Aan: al...@jt...; spr...@li...
> Onderwerp: Re: [Springframework-developer]=20
> PathMatchingUrlHandlerMapping
>
>
> This is very useful functionality. Good work!
>
> Thanks,
> Rod
>
> ----- Original Message -----
> From: "Alef Arendsen (JTeam)" <al...@jt...>
> To: <spr...@li...>
> Sent: Monday, July 14, 2003 2:38 PM
> Subject: [Springframework-developer] PathMatchingUrlHandlerMapping
>
>
> > Hi all,
> >
> > Since I work a lot with protected resources and stuff in webapps,=20
> > but on the other hand want to share and reuse different view across=20
> > multiple protected resources, I've implemented a somewhat more=20
> > advanced UrlHandlerMapping, one that kind of shows the behavior the=20
> > Ant patterns functionality also has, so:
> >
> > /**/view/listView.jsp for instance would both match on=20
> > /user/view/listView.jsp, but also on /admin/view/listView.jsp=20
> > /**/view/listView?.jsp for isntance would both match on=20
> > /user/view/listViewA.jsp but also on /admin/view/listViewB.jsp=20
> > /*view*.jsp for instance would both match on /view.jsp both also on=20
> > /view-employee.jsp and /detailed-view-employee.jsp
> >
> > I've included the additions and modifications I needed to do. These=20
> > are the following:
> >
> > *** Addition of PathMatchingUrlHandlerMapping
> > This class is extending SimpleUrlHandlerMapping and overrides the
> > lookupHandler() method from AbstractUrlHandlerMapping
> > *** Modification of AbstractUrlHandlerMapping
> > Because from the overriden lookupHandler() method I need to be able=20
> > to
>
> > inspect handlerMap property from the AbstractUrlHandlerMapping, I=20
> > made
>
> > this property protected instead of private
> > *** Addition of PathMatchingUrlHandlerMappingTestSuite and map3.xml=20
> > to
>
> > this package which is testing the PathMatchingUrlHandlerMapping
> >
> > I've been running the Clover stuff and managed to get the coverage=20
> > up to 87,2%, I hope that's up to standards for you guys?
> >
> > About the pathmatching principles, they're explained in the JavaDoc=20
> > of
>
> > the class itself. The algorithms are 'borrowed' from the Ant=20
> > SelectorUtils class. I've modified them to use Lists instead of=20
> > Vectors.
> >
> > It would be nice if you would be able to integrate them.
> >
> > Cheers,
> >
> > Alef Arendsen
> >
>
>

RE: [Springframework-developer] PathMatchingUrlHandlerMapping

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

Alef,

I've just browsed your code, and already intended to suggest to refactor =
the path matching stuff into a com.interface21.util.PathMatcher or the =
like, as it doesn't depend on handler mappings or even servlet classes. =
So fine, go ahead! I really welcome more flexible path resolution =
options. Guess why SimpleUrlHandlerMapping is called "simple"... ;-)

Regarding unified configuration: I actually gave some thoughts to this, =
but didn't reach any conclusion. The role of a HandlerMapping is to =
resolve a handler (i.e. Controller), while the role of a =
MethodNameResolver is to resolve a method within a certain handler (i.e. =
MultiActionController). As the latter can also work via explicit =
"action" parameter etc, I don't think we should mix these roles.

I added a "...*" mapping to AbstractUrlHandlerMapping (thus both =
BeanNameUrlHandlerMapping SimpleUrlHandlerMapping) some weeks ago, =
mainly to enable a single "/mymulti/*" mappings to a =
MultiActionController that can map sub paths like "/mymulti/myactionX" =
to its methods then. Previously, one had to repeat all those =
method-level mappings one-by-one on the HandlerMapping.

Of course, it makes sense to have similar path matching options on both!

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Monday, July 14, 2003 3:49 PM
To: al...@jt...; spr...@li...
Cc: j=FCrgen h=F6ller [werk3AT]
Subject: Re: [Springframework-developer] PathMatchingUrlHandlerMapping


It certainly would be handy for method name resolution. We need =
consistency
between these two things. Juergen, did you give any thought to having =
one
config handle both by default somehow?

Regards,
Rod

----- Original Message -----
From: "Alef Arendsen (JTeam)" <al...@jt...>
To: "'Rod Johnson'" <rod...@in...>;
<spr...@li...>
Sent: Monday, July 14, 2003 2:50 PM
Subject: RE: [Springframework-developer] PathMatchingUrlHandlerMapping


> Wait!!!  ;-)
>
> Right now I'm noticing that this functionality would also be verrrry
> handy for the methodname resolver...
>
> So I'll have to abstract the PathMatching stuff into a separate class
> (which makes testing even easier probably) and extend (probably) the
> PropertiesMethodNameResolver thingy as well...
>
> So if no objections here, I'll go ahead and do that as wel...
>
> Alef
>
>
> -----Oorspronkelijk bericht-----
> Van: Rod Johnson [mailto:rod...@in...]
> Verzonden: Monday, July 14, 2003 3:37 PM
> Aan: al...@jt...; spr...@li...
> Onderwerp: Re: [Springframework-developer] =
PathMatchingUrlHandlerMapping
>
>
> This is very useful functionality. Good work!
>
> Thanks,
> Rod
>
> ----- Original Message -----
> From: "Alef Arendsen (JTeam)" <al...@jt...>
> To: <spr...@li...>
> Sent: Monday, July 14, 2003 2:38 PM
> Subject: [Springframework-developer] PathMatchingUrlHandlerMapping
>
>
> > Hi all,
> >
> > Since I work a lot with protected resources and stuff in webapps, =
but
> > on the other hand want to share and reuse different view across
> > multiple protected resources, I've implemented a somewhat more
> > advanced UrlHandlerMapping, one that kind of shows the behavior the
> > Ant patterns functionality also has, so:
> >
> > /**/view/listView.jsp for instance would both match on
> > /user/view/listView.jsp, but also on /admin/view/listView.jsp
> > /**/view/listView?.jsp for isntance would both match on
> > /user/view/listViewA.jsp but also on /admin/view/listViewB.jsp
> > /*view*.jsp for instance would both match on /view.jsp both also on
> > /view-employee.jsp and /detailed-view-employee.jsp
> >
> > I've included the additions and modifications I needed to do. These
> > are the following:
> >
> > *** Addition of PathMatchingUrlHandlerMapping
> > This class is extending SimpleUrlHandlerMapping and overrides the
> > lookupHandler() method from AbstractUrlHandlerMapping
> > *** Modification of AbstractUrlHandlerMapping
> > Because from the overriden lookupHandler() method I need to be able =
to
>
> > inspect handlerMap property from the AbstractUrlHandlerMapping, I =
made
>
> > this property protected instead of private
> > *** Addition of PathMatchingUrlHandlerMappingTestSuite and map3.xml =
to
>
> > this package which is testing the PathMatchingUrlHandlerMapping
> >
> > I've been running the Clover stuff and managed to get the coverage =
up
> > to 87,2%, I hope that's up to standards for you guys?
> >
> > About the pathmatching principles, they're explained in the JavaDoc =
of
>
> > the class itself. The algorithms are 'borrowed' from the Ant
> > SelectorUtils class. I've modified them to use Lists instead of
> > Vectors.
> >
> > It would be nice if you would be able to integrate them.
> >
> > Cheers,
> >
> > Alef Arendsen
> >
>
>

Re: [Springframework-developer] PathMatchingUrlHandlerMapping

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

It certainly would be handy for method name resolution. We need consistency
between these two things. Juergen, did you give any thought to having one
config handle both by default somehow?

Regards,
Rod

----- Original Message -----
From: "Alef Arendsen (JTeam)" <al...@jt...>
To: "'Rod Johnson'" <rod...@in...>;
<spr...@li...>
Sent: Monday, July 14, 2003 2:50 PM
Subject: RE: [Springframework-developer] PathMatchingUrlHandlerMapping


> Wait!!!  ;-)
>
> Right now I'm noticing that this functionality would also be verrrry
> handy for the methodname resolver...
>
> So I'll have to abstract the PathMatching stuff into a separate class
> (which makes testing even easier probably) and extend (probably) the
> PropertiesMethodNameResolver thingy as well...
>
> So if no objections here, I'll go ahead and do that as wel...
>
> Alef
>
>
> -----Oorspronkelijk bericht-----
> Van: Rod Johnson [mailto:rod...@in...]
> Verzonden: Monday, July 14, 2003 3:37 PM
> Aan: al...@jt...; spr...@li...
> Onderwerp: Re: [Springframework-developer] PathMatchingUrlHandlerMapping
>
>
> This is very useful functionality. Good work!
>
> Thanks,
> Rod
>
> ----- Original Message -----
> From: "Alef Arendsen (JTeam)" <al...@jt...>
> To: <spr...@li...>
> Sent: Monday, July 14, 2003 2:38 PM
> Subject: [Springframework-developer] PathMatchingUrlHandlerMapping
>
>
> > Hi all,
> >
> > Since I work a lot with protected resources and stuff in webapps, but
> > on the other hand want to share and reuse different view across
> > multiple protected resources, I've implemented a somewhat more
> > advanced UrlHandlerMapping, one that kind of shows the behavior the
> > Ant patterns functionality also has, so:
> >
> > /**/view/listView.jsp for instance would both match on
> > /user/view/listView.jsp, but also on /admin/view/listView.jsp
> > /**/view/listView?.jsp for isntance would both match on
> > /user/view/listViewA.jsp but also on /admin/view/listViewB.jsp
> > /*view*.jsp for instance would both match on /view.jsp both also on
> > /view-employee.jsp and /detailed-view-employee.jsp
> >
> > I've included the additions and modifications I needed to do. These
> > are the following:
> >
> > *** Addition of PathMatchingUrlHandlerMapping
> > This class is extending SimpleUrlHandlerMapping and overrides the
> > lookupHandler() method from AbstractUrlHandlerMapping
> > *** Modification of AbstractUrlHandlerMapping
> > Because from the overriden lookupHandler() method I need to be able to
>
> > inspect handlerMap property from the AbstractUrlHandlerMapping, I made
>
> > this property protected instead of private
> > *** Addition of PathMatchingUrlHandlerMappingTestSuite and map3.xml to
>
> > this package which is testing the PathMatchingUrlHandlerMapping
> >
> > I've been running the Clover stuff and managed to get the coverage up
> > to 87,2%, I hope that's up to standards for you guys?
> >
> > About the pathmatching principles, they're explained in the JavaDoc of
>
> > the class itself. The algorithms are 'borrowed' from the Ant
> > SelectorUtils class. I've modified them to use Lists instead of
> > Vectors.
> >
> > It would be nice if you would be able to integrate them.
> >
> > Cheers,
> >
> > Alef Arendsen
> >
>
>

RE: [Springframework-developer] PathMatchingUrlHandlerMapping

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

Wait!!!  ;-)

Right now I'm noticing that this functionality would also be verrrry
handy for the methodname resolver...

So I'll have to abstract the PathMatching stuff into a separate class
(which makes testing even easier probably) and extend (probably) the
PropertiesMethodNameResolver thingy as well...

So if no objections here, I'll go ahead and do that as wel...

Alef


-----Oorspronkelijk bericht-----
Van: Rod Johnson [mailto:rod...@in...] 
Verzonden: Monday, July 14, 2003 3:37 PM
Aan: al...@jt...; spr...@li...
Onderwerp: Re: [Springframework-developer] PathMatchingUrlHandlerMapping


This is very useful functionality. Good work!

Thanks,
Rod

----- Original Message ----- 
From: "Alef Arendsen (JTeam)" <al...@jt...>
To: <spr...@li...>
Sent: Monday, July 14, 2003 2:38 PM
Subject: [Springframework-developer] PathMatchingUrlHandlerMapping


> Hi all,
> 
> Since I work a lot with protected resources and stuff in webapps, but 
> on the other hand want to share and reuse different view across 
> multiple protected resources, I've implemented a somewhat more 
> advanced UrlHandlerMapping, one that kind of shows the behavior the 
> Ant patterns functionality also has, so:
> 
> /**/view/listView.jsp for instance would both match on 
> /user/view/listView.jsp, but also on /admin/view/listView.jsp 
> /**/view/listView?.jsp for isntance would both match on 
> /user/view/listViewA.jsp but also on /admin/view/listViewB.jsp 
> /*view*.jsp for instance would both match on /view.jsp both also on 
> /view-employee.jsp and /detailed-view-employee.jsp
> 
> I've included the additions and modifications I needed to do. These 
> are the following:
> 
> *** Addition of PathMatchingUrlHandlerMapping
> This class is extending SimpleUrlHandlerMapping and overrides the
> lookupHandler() method from AbstractUrlHandlerMapping
> *** Modification of AbstractUrlHandlerMapping
> Because from the overriden lookupHandler() method I need to be able to

> inspect handlerMap property from the AbstractUrlHandlerMapping, I made

> this property protected instead of private
> *** Addition of PathMatchingUrlHandlerMappingTestSuite and map3.xml to

> this package which is testing the PathMatchingUrlHandlerMapping
> 
> I've been running the Clover stuff and managed to get the coverage up 
> to 87,2%, I hope that's up to standards for you guys?
> 
> About the pathmatching principles, they're explained in the JavaDoc of

> the class itself. The algorithms are 'borrowed' from the Ant 
> SelectorUtils class. I've modified them to use Lists instead of 
> Vectors.
> 
> It would be nice if you would be able to integrate them.
> 
> Cheers,
> 
> Alef Arendsen
> 

RE: [Springframework-developer] removing ObjectArrayUtils

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

I've just checked the size in the jar file: It's just 8 KB there. =
Obviously, there's a lot of air in the class ;-)

Some more statistics: It's by far our largest class file with ~1900 LOC =
in 58 KB (BeanWrapperImpl is next with ~900 LOC in 21 KB), amounting for =
~25% of the uncompressed spring-beans.jar (230 KB in total). That's what =
led me to question its role.

As I personally don't mind new Object() {...}, I probably won't use =
ObjectArrayUtils myself, but I can live with 8 KB in the =
spring-beans.jar file. I just don't particularly like such large helper =
classes... Hopefully noone ever suggests to extend the number of =
signatures to all permutations for 20 arguments ;-)

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Monday, July 14, 2003 12:53 PM
To: j=FCrgen h=F6ller [werk3AT];
spr...@li...
Subject: Re: [Springframework-developer] removing ObjectArrayUtils


I vote to keep it. I think it's a pain to have to write such methods =
(new
Object[] {whatever}). It is unfortunate about the footprint, maybe we =
could
have a distribution without it?

Also it has 100% test coverage, so we know all those methods work.

Regards,
Rod

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Monday, July 14, 2003 8:00 AM
Subject: [Springframework-developer] removing ObjectArrayUtils


Does anyone mind if I remove ObjectArrayUtils from com.interface21.util? =
I
don't really like its approach over having dozens of overloaded toArray
methods that take all kinds of arguments and convert them to an Object
array. What's so bad about

  new Object[] {"bla", "blabla"}

or

  new Object[] {new Integer(1), new Integer(2)}

after all? Is ObjectArrayUtils' syntax really significantly nicer, i.e.

  ObjectArrayUtils.toArray("bla", "blabla");

or

  ObjectArrayUtils.toArray(1, 2);

Given that it has to overload such an arbitrary number of argument
signatures, I don't consider that worth it. And let's not forget that
ObjectArrayUtils.java has 74 KB (!), the class file still 58 KB. I vote =
for
removing it, any application code that uses it (if any at all) is very =
easy
to convert (see above).

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] PathMatchingUrlHandlerMapping

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

I fully agree - I'll integrate it promptly.

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Monday, July 14, 2003 3:37 PM
To: al...@jt...; spr...@li...
Subject: Re: [Springframework-developer] PathMatchingUrlHandlerMapping


This is very useful functionality. Good work!

Thanks,
Rod

----- Original Message -----=20
From: "Alef Arendsen (JTeam)" <al...@jt...>
To: <spr...@li...>
Sent: Monday, July 14, 2003 2:38 PM
Subject: [Springframework-developer] PathMatchingUrlHandlerMapping


> Hi all,
>=20
> Since I work a lot with protected resources and stuff in webapps, but =
on
> the other hand want to share and reuse different view across multiple
> protected resources, I've implemented a somewhat more advanced
> UrlHandlerMapping, one that kind of shows the behavior the Ant =
patterns
> functionality also has, so:
>=20
> /**/view/listView.jsp for instance would both match on
> /user/view/listView.jsp, but also on /admin/view/listView.jsp
> /**/view/listView?.jsp for isntance would both match on
> /user/view/listViewA.jsp but also on /admin/view/listViewB.jsp
> /*view*.jsp for instance would both match on /view.jsp both also on
> /view-employee.jsp and /detailed-view-employee.jsp
>=20
> I've included the additions and modifications I needed to do. These =
are
> the following:
>=20
> *** Addition of PathMatchingUrlHandlerMapping
> This class is extending SimpleUrlHandlerMapping and overrides the
> lookupHandler() method from AbstractUrlHandlerMapping
> *** Modification of AbstractUrlHandlerMapping
> Because from the overriden lookupHandler() method I need to be able to
> inspect handlerMap property from the AbstractUrlHandlerMapping, I made
> this property protected instead of private
> *** Addition of PathMatchingUrlHandlerMappingTestSuite and map3.xml to
> this package which is testing the PathMatchingUrlHandlerMapping
>=20
> I've been running the Clover stuff and managed to get the coverage up =
to
> 87,2%, I hope that's up to standards for you guys?
>=20
> About the pathmatching principles, they're explained in the JavaDoc of
> the class itself. The algorithms are 'borrowed' from the Ant
> SelectorUtils class. I've modified them to use Lists instead of =
Vectors.
>=20
> It would be nice if you would be able to integrate them.
>=20
> Cheers,
>=20
> Alef Arendsen
>=20




-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] PathMatchingUrlHandlerMapping

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

This is very useful functionality. Good work!

Thanks,
Rod

----- Original Message ----- 
From: "Alef Arendsen (JTeam)" <al...@jt...>
To: <spr...@li...>
Sent: Monday, July 14, 2003 2:38 PM
Subject: [Springframework-developer] PathMatchingUrlHandlerMapping


> Hi all,
> 
> Since I work a lot with protected resources and stuff in webapps, but on
> the other hand want to share and reuse different view across multiple
> protected resources, I've implemented a somewhat more advanced
> UrlHandlerMapping, one that kind of shows the behavior the Ant patterns
> functionality also has, so:
> 
> /**/view/listView.jsp for instance would both match on
> /user/view/listView.jsp, but also on /admin/view/listView.jsp
> /**/view/listView?.jsp for isntance would both match on
> /user/view/listViewA.jsp but also on /admin/view/listViewB.jsp
> /*view*.jsp for instance would both match on /view.jsp both also on
> /view-employee.jsp and /detailed-view-employee.jsp
> 
> I've included the additions and modifications I needed to do. These are
> the following:
> 
> *** Addition of PathMatchingUrlHandlerMapping
> This class is extending SimpleUrlHandlerMapping and overrides the
> lookupHandler() method from AbstractUrlHandlerMapping
> *** Modification of AbstractUrlHandlerMapping
> Because from the overriden lookupHandler() method I need to be able to
> inspect handlerMap property from the AbstractUrlHandlerMapping, I made
> this property protected instead of private
> *** Addition of PathMatchingUrlHandlerMappingTestSuite and map3.xml to
> this package which is testing the PathMatchingUrlHandlerMapping
> 
> I've been running the Clover stuff and managed to get the coverage up to
> 87,2%, I hope that's up to standards for you guys?
> 
> About the pathmatching principles, they're explained in the JavaDoc of
> the class itself. The algorithms are 'borrowed' from the Ant
> SelectorUtils class. I've modified them to use Lists instead of Vectors.
> 
> It would be nice if you would be able to integrate them.
> 
> Cheers,
> 
> Alef Arendsen
> 

[Springframework-developer] PathMatchingUrlHandlerMapping

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

Hi all,

Since I work a lot with protected resources and stuff in webapps, but on
the other hand want to share and reuse different view across multiple
protected resources, I've implemented a somewhat more advanced
UrlHandlerMapping, one that kind of shows the behavior the Ant patterns
functionality also has, so:

/**/view/listView.jsp for instance would both match on
/user/view/listView.jsp, but also on /admin/view/listView.jsp
/**/view/listView?.jsp for isntance would both match on
/user/view/listViewA.jsp but also on /admin/view/listViewB.jsp
/*view*.jsp for instance would both match on /view.jsp both also on
/view-employee.jsp and /detailed-view-employee.jsp

I've included the additions and modifications I needed to do. These are
the following:

*** Addition of PathMatchingUrlHandlerMapping
This class is extending SimpleUrlHandlerMapping and overrides the
lookupHandler() method from AbstractUrlHandlerMapping
*** Modification of AbstractUrlHandlerMapping
Because from the overriden lookupHandler() method I need to be able to
inspect handlerMap property from the AbstractUrlHandlerMapping, I made
this property protected instead of private
*** Addition of PathMatchingUrlHandlerMappingTestSuite and map3.xml to
this package which is testing the PathMatchingUrlHandlerMapping

I've been running the Clover stuff and managed to get the coverage up to
87,2%, I hope that's up to standards for you guys?

About the pathmatching principles, they're explained in the JavaDoc of
the class itself. The algorithms are 'borrowed' from the Ant
SelectorUtils class. I've modified them to use Lists instead of Vectors.

It would be nice if you would be able to integrate them.

Cheers,

Alef Arendsen

Re: [Springframework-developer] removing ObjectArrayUtils

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

I vote to keep it. I think it's a pain to have to write such methods (new
Object[] {whatever}). It is unfortunate about the footprint, maybe we could
have a distribution without it?

Also it has 100% test coverage, so we know all those methods work.

Regards,
Rod

----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Monday, July 14, 2003 8:00 AM
Subject: [Springframework-developer] removing ObjectArrayUtils


Does anyone mind if I remove ObjectArrayUtils from com.interface21.util? I
don't really like its approach over having dozens of overloaded toArray
methods that take all kinds of arguments and convert them to an Object
array. What's so bad about

  new Object[] {"bla", "blabla"}

or

  new Object[] {new Integer(1), new Integer(2)}

after all? Is ObjectArrayUtils' syntax really significantly nicer, i.e.

  ObjectArrayUtils.toArray("bla", "blabla");

or

  ObjectArrayUtils.toArray(1, 2);

Given that it has to overload such an arbitrary number of argument
signatures, I don't consider that worth it. And let's not forget that
ObjectArrayUtils.java has 74 KB (!), the class file still 58 KB. I vote for
removing it, any application code that uses it (if any at all) is very easy
to convert (see above).

Juergen


DI Jürgen Höller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] RE: Tags using expression language?? & Petclinic

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

Ok, I can implement it all, no problem, however, I've got to do it in my =
spare time, which means in the evenings, because I have to do some other =
things this week as well...

So it'll probably finished by Thursday evening... If that's alright with =
you?

Cheers,

Alef

-----Oorspronkelijk bericht-----
Van: spr...@li... =
[mailto:spr...@li...] Namens =
Alef Arendsen (JTeam)
Verzonden: Sunday, July 13, 2003 7:27 PM
Aan: 'Ken Krebs'; 'j=C3=BCrgen h=C3=B6ller [werk3AT]'
CC: spr...@li...
Onderwerp: [Springframework-developer] RE: Tags using expression =
language?? & Petclinic


I'm currently checking out the sourcecode. Somehow I wasn't able to =
during the last couple of days. Well, anyway, I'll have a look into it =
and I'll let you know tomorrow...

Cheers,

Alef

-----Oorspronkelijk bericht-----
Van: Ken Krebs [mailto:kk...@kk...]
Verzonden: Saturday, July 12, 2003 6:22 PM
Aan: j=C3=BCrgen h=C3=B6ller [werk3AT]; al...@jt...
CC: spr...@li...
Onderwerp: Tags using expression language?? & Petclinic


Eliminating repetitive code in the jsp's is something I'd very much like =

to see. Alef: thanks for your contribution, it looks like it will help.

I've been in the process lately of  refactoring Petclinic's Clinic=20
implementation along with code tightening and documentation improvements =

and am just about ready to commit the changes. I WILL commit these=20
changes sometime later today. A couple of jsp's have minor changes.

Alef: If you would like to make the changes to the jsp's, please go=20
ahead. If not, I'll do it. Please let me know if you will be doing it.

Regards,
Ken
=20
j=C3=BCrgen h=C3=B6ller [werk3AT] wrote:

>I've introduced support for EL on tag attributes yesterday, already
>committed. Thanks for the idea and the prototype, Alef! I hope you are =
satisfied with the integration. You're very welcome to try it out :-)
>=20
>There's a new ExpressionEvaluationsUtils class now in
>com.interface21.web.util, taking a String argument value and parsing it =
to Object, String, int, or boolean. It will just attempt EL evaluation =
if the value starts with "${", else it will simply parse the value with =
standard means.
>=20
>All of Spring's tags use this class now for all attributes, simply
>delegating to the respective ExpressionEvaluationsUtils method in each =
setter. This means that all attributes still accept normal String values =
as before (like <i21:bind path=3D"person.name">), but also EL =
expressions (like <i21:bind path=3D"${bindPath}">).
>=20
>For EL evaluation, ExpressionEvaluationsUtils depends on Jakarta's JSTL
>implementation (standard.jar). It doesn't have a runtime dependency if =
just parsing normal String values though, as it delegates EL evaluation =
to an inner class that will just get loaded in case of actual EL =
expressions. So you'll just need the Jakarta JSTL implementation in your =
classpath if you actually use EL attribute values on tags.
>=20
>BTW, our AopProxy uses a similar mechanism to avoid a runtime
>dependency on CGLIB. If just proxying interfaces, it will use standard =
J2SE proxies. Only if you try to proxy a class itself, it will invoke =
CGLIB by delegating to a respective inner class.
>=20
>Finally, we should adapt PetClinic to use EL expressions on its bind
>tags. Alef has already shown the way in the prototype that he sent. =
Ken, what do you think? Would you like Alef to do this?
>=20
>Juergen
>=20
>=20
>
>	-----Urspr=C3=BCngliche Nachricht-----=20
>	Von: j=C3=BCrgen h=C3=B6ller [werk3AT]=20
>	Gesendet: Fr 11.07.2003 08:13=20
>	An: al...@jt...; spr...@li...=20
>	Cc:=20
>	Betreff: Re: [Springframework-developer] Tags using expression
>language??
>=09
>=09
>
>	Alef,
>=09
>	I've just browsed your code - this looks very interesting! It makes
>iterating such repetitive form fields like in the petclinic much =
easier. I'll have a look at the implementation details, and if =
everything works out I'll add a clean room version to the main source =
tree promptly.
>=09
>	I wonder if we could make that work with any JSTL implementation, not
>just the Jakarta one, although I wouldn't mind a dependency on the =
latter for this feature.
>=09
>	Cool stuff :-)
>=09
>	Juergen
>=09
>=09
>=09
>	        -----Urspr=C3=BCngliche Nachricht-----
>	        Von: Alef Arendsen [mailto:al...@jt...]
>	        Gesendet: Di 08.07.2003 19:43
>	        An: j=C3=BCrgen h=C3=B6ller [werk3AT]; =
spr...@li...
>	        Cc:
>	        Betreff: RE: [Springframework-developer] Tags using expression
>language??
>	      =20
>	      =20
>=09
>	        Ok, here we go...
>	      =20
>	        Like you said, at first glance, it does not look like the =
i21:bind tag
>	        needs expressionalization (hmmm, nice huh ;-). However, in the =
petclinic
>	        demo app I'm seeing a lot of input.jsps in the jsp/fields =
directory.
>	        These are things I'm hoping to solve using for instance =
EL-based tags...
>	        Attached you'll find a reworked version of the ownerForm. It =
does not
>	        use the JSPs from the fields directory anymore, but uses only =
one
>	        input.jsp that uses the bindstatus object to create the input
>field.
>	      =20
>	        Ok, it's still all rough and reworking the tags is a little =
bit more
>	        work than the 15 minutes I spent on it now, but maybe you're =
getting the
>	        idea.
>	      =20
>	        Consequences for adding / reworking the tags:
>	      =20
>	        1. dependency on jakarta-jstl-1.0.3 (jakarta.apache.org/taglib =
-->
>	        standard).
>	        2. dependency on jstl-1.0.3 (java.sun.com)
>	        3. In case you want to have both version in there, an =
extending class
>	        for each tag
>	        4. For each tag, a BeanInfo class
>	        5. I wasn't able to use the EvalHelper from jakarta, so I =
copied it
>	        (hmmm... not so nice, is it ;-)
>	      =20
>	        Probably I don't have time this week or something to refactor =
them to be
>	        all EL-based... Just let me know if you'd like it.
>	      =20
>	        Well, that's it for now, still discovering really cool =
features and
>	        already running out (brain)memory to think up everything I =
could do with
>	        Spring ;-)
>	      =20
>	        Cheers,
>	      =20
>	        Alef
>	      =20
>=09
>	=
N=18HS^=E9=9A=8A[){([j=1FJ=EB=A2=BAky=C6=AE^=D8=A7j+x:0Z=1Au=DA=95g*)jw`z=
=D6=9F=E7=9B=A20
>	Z(~(W(}iT)~{
>	+=D7=AFzZ)zXX*kx=1F=C5=A0u=DE=96^X(=1E~zwilq zlX)=DF=A3))~{
>	+=D7=AFzZ)
>
>?????????????????????????????????????????=D3=86+=12=17?^?=E9=9A=8A[)?{(?=
?[??=DA=AD?(~?+??=E9=AE=8A=1FY?
>=DA=A6??j?h??^??-?x?????:0?Z=1Aw?jU?l????=DD=81?Z~??n?$?=0C0???j?=1F??(?=
??W???(}?i?_???????????????????????????????????*k?x=1F???=C5=A0??=D7=AFzZ=
)z???X??X??*k?x=1F???=C5=A0??=D7=AFzZ)z???l??.?=C7=9F??=1E?w???i????+-??(=
??=1E~??{?=DE=B7?b????+-?w???k?x=1F???=C5=A0??=D7=AFzZ)
>
>
> =20
>




-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book. =
www.parasoft.com/bulletproofapps1 =
_______________________________________________
Springframework-developer mailing list =
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] removing ObjectArrayUtils

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

Does anyone mind if I remove ObjectArrayUtils from com.interface21.util? =
I don't really like its approach over having dozens of overloaded =
toArray methods that take all kinds of arguments and convert them to an =
Object array. What's so bad about

  new Object[] {"bla", "blabla"}

or

  new Object[] {new Integer(1), new Integer(2)}

after all? Is ObjectArrayUtils' syntax really significantly nicer, i.e.

  ObjectArrayUtils.toArray("bla", "blabla");

or

  ObjectArrayUtils.toArray(1, 2);

Given that it has to overload such an arbitrary number of argument =
signatures, I don't consider that worth it. And let's not forget that =
ObjectArrayUtils.java has 74 KB (!), the class file still 58 KB. I vote =
for removing it, any application code that uses it (if any at all) is =
very easy to convert (see above).

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG

[Springframework-developer] FW: [Springframework-user] Proxy bean configuration Help!!!!

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

SW50ZW5kZWQgZm9yIHRoZSBkZXZlbG9wZXIgbGlzdC4uLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQpGcm9tOiBqw7xyZ2VuIGjDtmxsZXIgW3dlcmszQVRdIA0KU2VudDogTW9uZGF5
LCBKdWx5IDE0LCAyMDAzIDg6MDAgQU0NClRvOiBSb2QgSm9obnNvbjsgQ3VydG5leSBKYWNvYnMN
CkNjOiBzcHJpbmdmcmFtZXdvcmstdXNlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNClN1YmplY3Q6
IFJlOiBbU3ByaW5nZnJhbWV3b3JrLXVzZXJdIFByb3h5IGJlYW4gY29uZmlndXJhdGlvbiBIZWxw
ISEhIQ0KDQoNClRvIGdldCBpdCBvdXQgQVNBUCwgd2hhdCBlbHNlPyA7LSkgU2VyaW91c2x5LCBJ
J20ga2VlbiBvbiBnZXR0aW5nIGl0IG91dCBhdCB0aGUgZW5kIG9mIHRoaXMgd2Vlay4gQW55IG9i
amVjdGlvbnM/IEkgd2lsbCBzaW1wbHkgcG9saXNoIHRoZSBkb2NzIGFub3RoZXIgYml0LCBidXQg
dGhhdCdzIGl0IGZyb20gbXkgc2lkZS4gSSdkIGFsc28gbGlrZSB0byBpbmNsdWRlIHNldHVwIG9w
dGlvbnMgaW4gb3VyIERhdGEgQWNjZXNzIGFydGljbGUgb24gdGhlIEhpYmVybmF0ZSB3ZWJzaXRl
IHByb21wdGx5LCBpLmUuIExvY2FsU2Vzc2lvbkZhY3RvcnlCZWFuIGFuZCBIaWJlcm5hdGVUcmFu
c2FjdGlvbk1hbmFnZXIgYmVhbiBkZWZpbml0aW9ucywgd2hpY2ggc2hvdWxkIGFscmVhZHkgZmVh
dHVyZSB0aGUgbmV3IG9wdGlvbnMgaW4gMC45LjEuDQogDQpPZiBjb3Vyc2UgdGhlIG1pc3Npbmcg
YW9wYWxsaWFuY2UuamFyIHdpbGwgYmUgY29udGFpbmVkIGluIDAuOS4xLiBJJ3ZlIGFscmVhZHkg
bW9kaWZpZWQgb3VyIGJ1aWxkIHNjcmlwdCBhY2NvcmRpbmdseSByaWdodCBhZnRlciBJIGhhZCBu
b3RpY2VkIHRoZSBqYXIncyBhYnNlbmNlIGluIDAuOS4gQlRXLCB3ZSBzdGlsbCBoYXZlIG5laXRo
ZXIgQU9QIEFsbGlhbmNlIHNvdXJjZXMgbm9yIEphdmFkb2NzIGluIHRoZSBTcHJpbmcgQ1ZTLiBS
b2QsIHdvdWxkIHlvdSBjb25zaWRlciB0aGVtIHdvcnRoIGFkZGluZyB0byBvdXIgZGlzdHJpYnV0
aW9uPw0KIA0KRmVhdHVyZXdpc2UsIHdlIHNob3VsZCBiZSByZWFkeSBmb3IgMC45LjEsIHdpdGgg
dmFyaW91cyBzbWFsbCBlbmhhbmNlbWVudHM6DQogDQotIGNsZWFuZWQgbWFpbiBwYWNrYWdlczog
aW50cm9kdWNlZCAic2FuZGJveCIsIG1pbm9yIGNsYXNzIG1vdmVzIGFuZCByZW5hbWluZ3MNCi0g
aW1wcm92ZWQgZG9jcyBhbmQgc2FtcGxlIGFwcGxpY2F0aW9ucyAobm90ZTogInBhZ2VkbGlzdCIg
aGFzIGJlZW4gdHVybmVkIGludG8gImNvdW50cmllcyIpDQotIHJld29ya2VkIGRpc3RyaWJ1dGlv
biBKYXIgZmlsZXMgZm9yIHVzYWdlIHNjZW5hcmlvczogInNwcmluZy1iZWFucyIsICJzcHJpbmct
amRiYyIsICJzcHJpbmctZnVsbCINCi0gQ0dMSUIgc3VwcG9ydCB3aXRoaW4gdGhlIEFPUCBmcmFt
ZXdvcmssIHRvIGJlIGFibGUgdG8gcHJveHkgY2xhc3NlcyBpbnN0ZWFkIG9mIGp1c3QgaW50ZXJm
YWNlcw0KLSByZXdvcmtlZCBQcm9wZXJ0eVJlc291cmNlQ29uZmlndXJlciwgZm9yIG92ZXJyaWRp
bmcgYmVhbiBwcm9wZXJ0eSB2YWx1ZXMgaW4gY29udGV4dCBkZWZpbml0aW9ucw0KLSBtb3JlIEhp
YmVybmF0ZSBzZXR1cCBvcHRpb25zIHZpYSBMb2NhbFNlc3Npb25GYWN0b3J5QmVhbg0KLSBuZXcg
Y29udmVuaWVuY2UgbWV0aG9kcyBvbiBIaWJlcm5hdGVUZW1wbGF0ZSwgZm9yIHNpbmdsZS1zdGVw
IGFjdGlvbnMNCi0gbW9yZSBKRE8gc2V0dXAgb3B0aW9ucyB2aWEgTG9jYWxQZXJzaXN0ZW5jZU1h
bmFnZXJGYWN0b3J5QmVhbg0KLSByZXdvcmtlZCBzaW1wbGUgSk5ESSBTUEkgaW1wbGVtZW50YXRp
b24gZm9yIG5vbi1KMkVFIGVudmlyb25tZW50cw0KLSBpbnRyb2R1Y2VkIEpTUCBFTCBzdXBwb3J0
IGZvciBhdHRyaWJ1dGVzIGluIHRoZSBTcHJpbmcgdGFnIGxpYnJhcnkNCiANClBsZWFzZSBub3Rp
ZnkgbWUgaWYgc29tZXRoaW5nIGlzIG1pc3NpbmcsIGFzIHRoaXMgbGlzdCBzaG91bGQgbWFrZSB1
cCB0aGUgcmVsZWFzZSBjaGFuZ2UgbG9nLg0KIA0KUmVnYXJkaW5nIG91ciBuZXh0IHJlbGVhc2Ug
YWZ0ZXIgMC45LjE6IFdlIHNob3VsZCBkZWNpZGUgaWYgd2Ugd2lsbCBkbyBhbm90aGVyIDAuOSBw
b2ludCByZWxlYXNlLCBvciBhbHJlYWR5IGFpbSBhdCBhIGZpcnN0IDEuMCBSZWxlYXNlIENhbmRp
ZGF0ZSB3aXRoIG9yZy5zcHJpbmdmcmFtZXdvcmsgcGFja2FnZXMgYW5kIHN0YWJpbGl6ZWQgQVBJ
cy4gSSBzdWdnZXN0IHRvIGdvIGZvciBhIDAuOS4yIHJlbGVhc2UgYXQgdGhlIGVuZCBvZiBKdWx5
LCBhcyBJIGV4cGVjdCBudW1lcm91cyBzbWFsbCByZXdvcmtpbmdzLiAxLjAgUkNzIHdpbGwgbmVl
ZCBzdGFiaWxpemVkIEFPUCBBbGxpYW5jZSBBUElzIHRvbywgc28gd2Ugd2lsbCBzb21ld2hhdCBk
ZXBlbmQgb24gdGhlIGFsbGlhbmNlJ3MgcHJvZ3Jlc3Npb24uIFdoYXQgZG8geW91IHRoaW5rPw0K
IA0KSnVlcmdlbg0KIA0KIA0KDQoJLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSAN
CglWb246IFJvZCBKb2huc29uIFttYWlsdG86cm9kLmpvaG5zb25AaW50ZXJmYWNlMjEuY29tXSAN
CglHZXNlbmRldDogU28gMTMuMDcuMjAwMyAyMTozOCANCglBbjogQ3VydG5leSBKYWNvYnMgDQoJ
Q2M6IHNwcmluZ2ZyYW1ld29yay11c2VyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCANCglCZXRyZWZm
OiBSZTogW1NwcmluZ2ZyYW1ld29yay11c2VyXSBQcm94eSBiZWFuIGNvbmZpZ3VyYXRpb24gSGVs
cCEhISENCgkNCgkNCg0KCVlvdSBuZWVkIHRoZSBBT1AgQWxsaWFuY2UgamFyLCB3aGljaCBpcyBt
aXNzaW5nIGZyb20gdGhlIDAuOSByZWxlYXNlLiBUaGlzDQoJZmlsZSBpcyBpbiBDVlMgKHVuZGVy
IC9saWIpDQoJYW5kIHdpbGwgYmUgaW4gdGhlIG5leHQgcG9pbnQgcmVsZWFzZS4NCgkNCglKdWVy
Z2VuLCB3aGF0J3Mgb3VyIHBsYW4gb24gdGhpcz8NCgkNCglSZWdhcmRzLA0KCVJvZA0KCQ0KCS0t
LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCglGcm9tOiAiQ3VydG5leSBKYWNvYnMiIDxjLmN1
cnRuZXlqYWNvYnNAY29tY2FzdC5uZXQ+DQoJVG86ICJSb2QgSm9obnNvbiIgPHJvZC5qb2huc29u
QGludGVyZmFjZTIxLmNvbT4NCglTZW50OiBTYXR1cmRheSwgSnVseSAxMiwgMjAwMyA2OjUzIFBN
DQoJU3ViamVjdDogUmU6IFtTcHJpbmdmcmFtZXdvcmstdXNlcl0gUHJveHkgYmVhbiBjb25maWd1
cmF0aW9uIEhlbHAhISEhDQoJDQoJDQoJPiBIaSBSb2QsIEkgcmVjaWV2ZWQgdGhlIGZvbGxvd2lu
ZyBzdGFjayB0cmFjZToNCgk+DQoJPiBqYXZhLmxhbmcuTm9DbGFzc0RlZkZvdW5kRXJyb3I6IG9y
Zy9hb3BhbGxpYW5jZS9NZXRob2RJbnRlcmNlcHRvcg0KCT4gYXQgamF2YS5sYW5nLkNsYXNzTG9h
ZGVyLmRlZmluZUNsYXNzMChOYXRpdmUgTWV0aG9kKQ0KCT4gYXQgamF2YS5sYW5nLkNsYXNzTG9h
ZGVyLmRlZmluZUNsYXNzKENsYXNzTG9hZGVyLmphdmE6NTA5KQ0KCT4gYXQgamF2YS5zZWN1cml0
eS5TZWN1cmVDbGFzc0xvYWRlci5kZWZpbmVDbGFzcyhTZWN1cmVDbGFzc0xvYWRlci5qYXZhOjEy
MykNCgk+IGF0IGphdmEubmV0LlVSTENsYXNzTG9hZGVyLmRlZmluZUNsYXNzKFVSTENsYXNzTG9h
ZGVyLmphdmE6MjQ2KQ0KCT4gYXQgamF2YS5uZXQuVVJMQ2xhc3NMb2FkZXIuYWNjZXNzJDEwMChV
UkxDbGFzc0xvYWRlci5qYXZhOjU0KQ0KCT4gYXQgamF2YS5uZXQuVVJMQ2xhc3NMb2FkZXIkMS5y
dW4oVVJMQ2xhc3NMb2FkZXIuamF2YToxOTMpDQoJPiBhdCBqYXZhLnNlY3VyaXR5LkFjY2Vzc0Nv
bnRyb2xsZXIuZG9Qcml2aWxlZ2VkKE5hdGl2ZSBNZXRob2QpDQoJPiBhdCBqYXZhLm5ldC5VUkxD
bGFzc0xvYWRlci5maW5kQ2xhc3MoVVJMQ2xhc3NMb2FkZXIuamF2YToxODYpDQoJPiBhdCBqYXZh
LmxhbmcuQ2xhc3NMb2FkZXIubG9hZENsYXNzKENsYXNzTG9hZGVyLmphdmE6MzA2KQ0KCT4gYXQg
c3VuLm1pc2MuTGF1bmNoZXIkQXBwQ2xhc3NMb2FkZXIubG9hZENsYXNzKExhdW5jaGVyLmphdmE6
MjY1KQ0KCT4gYXQgamF2YS5sYW5nLkNsYXNzTG9hZGVyLmxvYWRDbGFzcyhDbGFzc0xvYWRlci5q
YXZhOjI2MikNCgk+IGF0IGphdmEubGFuZy5DbGFzc0xvYWRlci5sb2FkQ2xhc3NJbnRlcm5hbChD
bGFzc0xvYWRlci5qYXZhOjMyMikNCgk+IGF0IGphdmEubGFuZy5DbGFzc0xvYWRlci5kZWZpbmVD
bGFzczAoTmF0aXZlIE1ldGhvZCkNCgk+IGF0IGphdmEubGFuZy5DbGFzc0xvYWRlci5kZWZpbmVD
bGFzcyhDbGFzc0xvYWRlci5qYXZhOjUwOSkNCgk+IGF0IGphdmEuc2VjdXJpdHkuU2VjdXJlQ2xh
c3NMb2FkZXIuZGVmaW5lQ2xhc3MoU2VjdXJlQ2xhc3NMb2FkZXIuamF2YToxMjMpDQoJPiBhdCBq
YXZhLm5ldC5VUkxDbGFzc0xvYWRlci5kZWZpbmVDbGFzcyhVUkxDbGFzc0xvYWRlci5qYXZhOjI0
NikNCgk+IGF0IGphdmEubmV0LlVSTENsYXNzTG9hZGVyLmFjY2VzcyQxMDAoVVJMQ2xhc3NMb2Fk
ZXIuamF2YTo1NCkNCgk+IGF0IGphdmEubmV0LlVSTENsYXNzTG9hZGVyJDEucnVuKFVSTENsYXNz
TG9hZGVyLmphdmE6MTkzKQ0KCT4gYXQgamF2YS5zZWN1cml0eS5BY2Nlc3NDb250cm9sbGVyLmRv
UHJpdmlsZWdlZChOYXRpdmUgTWV0aG9kKQ0KCT4gYXQgamF2YS5uZXQuVVJMQ2xhc3NMb2FkZXIu
ZmluZENsYXNzKFVSTENsYXNzTG9hZGVyLmphdmE6MTg2KQ0KCT4gYXQgamF2YS5sYW5nLkNsYXNz
TG9hZGVyLmxvYWRDbGFzcyhDbGFzc0xvYWRlci5qYXZhOjMwNikNCgk+IGF0IHN1bi5taXNjLkxh
dW5jaGVyJEFwcENsYXNzTG9hZGVyLmxvYWRDbGFzcyhMYXVuY2hlci5qYXZhOjI2NSkNCgk+IGF0
IGphdmEubGFuZy5DbGFzc0xvYWRlci5sb2FkQ2xhc3MoQ2xhc3NMb2FkZXIuamF2YToyNjIpDQoJ
PiBhdCBqYXZhLmxhbmcuQ2xhc3NMb2FkZXIubG9hZENsYXNzSW50ZXJuYWwoQ2xhc3NMb2FkZXIu
amF2YTozMjIpDQoJPiBhdCBqYXZhLmxhbmcuQ2xhc3NMb2FkZXIuZGVmaW5lQ2xhc3MwKE5hdGl2
ZSBNZXRob2QpDQoJPiBhdCBqYXZhLmxhbmcuQ2xhc3NMb2FkZXIuZGVmaW5lQ2xhc3MoQ2xhc3NM
b2FkZXIuamF2YTo1MDkpDQoJPiBhdCBqYXZhLnNlY3VyaXR5LlNlY3VyZUNsYXNzTG9hZGVyLmRl
ZmluZUNsYXNzKFNlY3VyZUNsYXNzTG9hZGVyLmphdmE6MTIzKQ0KCT4gYXQgamF2YS5uZXQuVVJM
Q2xhc3NMb2FkZXIuZGVmaW5lQ2xhc3MoVVJMQ2xhc3NMb2FkZXIuamF2YToyNDYpDQoJPiBhdCBq
YXZhLm5ldC5VUkxDbGFzc0xvYWRlci5hY2Nlc3MkMTAwKFVSTENsYXNzTG9hZGVyLmphdmE6NTQp
DQoJPiBhdCBqYXZhLm5ldC5VUkxDbGFzc0xvYWRlciQxLnJ1bihVUkxDbGFzc0xvYWRlci5qYXZh
OjE5MykNCgk+IGF0IGphdmEuc2VjdXJpdHkuQWNjZXNzQ29udHJvbGxlci5kb1ByaXZpbGVnZWQo
TmF0aXZlIE1ldGhvZCkNCgk+IGF0IGphdmEubmV0LlVSTENsYXNzTG9hZGVyLmZpbmRDbGFzcyhV
UkxDbGFzc0xvYWRlci5qYXZhOjE4NikNCgk+IGF0IGphdmEubGFuZy5DbGFzc0xvYWRlci5sb2Fk
Q2xhc3MoQ2xhc3NMb2FkZXIuamF2YTozMDYpDQoJPiBhdCBzdW4ubWlzYy5MYXVuY2hlciRBcHBD
bGFzc0xvYWRlci5sb2FkQ2xhc3MoTGF1bmNoZXIuamF2YToyNjUpDQoJPiBhdCBqYXZhLmxhbmcu
Q2xhc3NMb2FkZXIubG9hZENsYXNzKENsYXNzTG9hZGVyLmphdmE6MjYyKQ0KCT4gYXQgamF2YS5s
YW5nLkNsYXNzTG9hZGVyLmxvYWRDbGFzc0ludGVybmFsKENsYXNzTG9hZGVyLmphdmE6MzIyKQ0K
CT4gYXQgamF2YS5sYW5nLkNsYXNzLmZvck5hbWUwKE5hdGl2ZSBNZXRob2QpDQoJPiBhdCBqYXZh
LmxhbmcuQ2xhc3MuZm9yTmFtZShDbGFzcy5qYXZhOjIwNykNCgk+IGF0DQoJY29tLmNhdWNoby51
dGlsLkR5bmFtaWNDbGFzc0xvYWRlci5sb2FkQ2xhc3MoRHluYW1pY0NsYXNzTG9hZGVyLmphdmE6
NTAwKQ0KCT4gYXQgamF2YS5sYW5nLkNsYXNzTG9hZGVyLmxvYWRDbGFzcyhDbGFzc0xvYWRlci5q
YXZhOjI2MikNCgk+IGF0IGphdmEubGFuZy5DbGFzc0xvYWRlci5sb2FkQ2xhc3NJbnRlcm5hbChD
bGFzc0xvYWRlci5qYXZhOjMyMikNCgk+IGF0IGphdmEubGFuZy5DbGFzcy5mb3JOYW1lMChOYXRp
dmUgTWV0aG9kKQ0KCT4gYXQgamF2YS5sYW5nLkNsYXNzLmZvck5hbWUoQ2xhc3MuamF2YToyMDcp
DQoJPiBhdA0KCWNvbS5jYXVjaG8udXRpbC5EeW5hbWljQ2xhc3NMb2FkZXIubG9hZENsYXNzKER5
bmFtaWNDbGFzc0xvYWRlci5qYXZhOjUwMCkNCgk+IGF0IGphdmEubGFuZy5DbGFzc0xvYWRlci5s
b2FkQ2xhc3MoQ2xhc3NMb2FkZXIuamF2YToyNjIpDQoJPiBhdCBqYXZhLmxhbmcuQ2xhc3NMb2Fk
ZXIubG9hZENsYXNzSW50ZXJuYWwoQ2xhc3NMb2FkZXIuamF2YTozMjIpDQoJPiBhdCBqYXZhLmxh
bmcuQ2xhc3MuZm9yTmFtZTAoTmF0aXZlIE1ldGhvZCkNCgk+IGF0IGphdmEubGFuZy5DbGFzcy5m
b3JOYW1lKENsYXNzLmphdmE6MjA3KQ0KCT4gYXQNCgljb20uY2F1Y2hvLnV0aWwuRHluYW1pY0Ns
YXNzTG9hZGVyLmxvYWRDbGFzcyhEeW5hbWljQ2xhc3NMb2FkZXIuamF2YTo1MDApDQoJPiBhdCBq
YXZhLmxhbmcuQ2xhc3NMb2FkZXIubG9hZENsYXNzKENsYXNzTG9hZGVyLmphdmE6MjYyKQ0KCT4g
YXQgamF2YS5sYW5nLkNsYXNzTG9hZGVyLmxvYWRDbGFzc0ludGVybmFsKENsYXNzTG9hZGVyLmph
dmE6MzIyKQ0KCT4gYXQgamF2YS5sYW5nLkNsYXNzLmZvck5hbWUwKE5hdGl2ZSBNZXRob2QpDQoJ
PiBhdCBqYXZhLmxhbmcuQ2xhc3MuZm9yTmFtZShDbGFzcy5qYXZhOjIwNykNCgk+IGF0DQoJPg0K
CWNvbS5pbnRlcmZhY2UyMS5iZWFucy5mYWN0b3J5LnhtbC5YbWxCZWFuRmFjdG9yeS5wYXJzZUJl
YW5EZWZpbml0aW9uKFhtbEJlYW4NCglGYWN0b3J5LmphdmE6MjgzKQ0KCT4gYXQNCgk+DQoJY29t
LmludGVyZmFjZTIxLmJlYW5zLmZhY3RvcnkueG1sLlhtbEJlYW5GYWN0b3J5LmxvYWRCZWFuRGVm
aW5pdGlvbihYbWxCZWFuRg0KCWFjdG9yeS5qYXZhOjI1MSkNCgk+IGF0DQoJPg0KCWNvbS5pbnRl
cmZhY2UyMS5iZWFucy5mYWN0b3J5LnhtbC5YbWxCZWFuRmFjdG9yeS5sb2FkQmVhbkRlZmluaXRp
b25zKFhtbEJlYW4NCglGYWN0b3J5LmphdmE6MjMzKQ0KCT4gYXQNCgk+DQoJY29tLmludGVyZmFj
ZTIxLmJlYW5zLmZhY3RvcnkueG1sLlhtbEJlYW5GYWN0b3J5LmxvYWRCZWFuRGVmaW5pdGlvbnMo
WG1sQmVhbg0KCUZhY3RvcnkuamF2YToyMDApDQoJPiBhdA0KCT4NCgljb20uaW50ZXJmYWNlMjEu
YmVhbnMuZmFjdG9yeS54bWwuWG1sQmVhbkZhY3RvcnkuPGluaXQ+KFhtbEJlYW5GYWN0b3J5Lmph
dmE6DQoJMTQ4KQ0KCT4gYXQNCgk+DQoJY29tLmludGVyZmFjZTIxLmNvbnRleHQuc3VwcG9ydC5B
YnN0cmFjdFhtbEFwcGxpY2F0aW9uQ29udGV4dC5yZWZyZXNoQmVhbkZhYw0KCXRvcnkoQWJzdHJh
Y3RYbWxBcHBsaWNhdGlvbkNvbnRleHQuamF2YTo0MCkNCgk+IGF0DQoJPg0KCWNvbS5pbnRlcmZh
Y2UyMS5jb250ZXh0LnN1cHBvcnQuQWJzdHJhY3RBcHBsaWNhdGlvbkNvbnRleHQucmVmcmVzaChB
YnN0cmFjdEENCglwcGxpY2F0aW9uQ29udGV4dC5qYXZhOjIwNykNCgk+IGF0IGNvbS5pbnRlcmZh
DQoJPg0KCT4NCgk+DQoJPg0KCT4gVGhhbmsgZm9yIHJlcGx5aW5nLg0KCT4NCgk+IF9DSg0KCT4N
Cgk+DQoJPg0KCT4gT24gU3VuZGF5IDEzIEp1bHkgMjAwMyAwMjoxOSBhbSwgUm9kIEpvaG5zb24g
d3JvdGU6DQoJPiA+IFdoYXQgZXJyb3IgaXMgaXQgcHJvZHVjaW5nPyBDYW4geW91IHNlbmQgYSBz
dGFjayB0cmFjZT8gSSdtIHZlcnkga2VlbiB3ZQ0KCT4gPiBpbXByb3ZlIGVycm9yIG1lc3NhZ2Vz
IGNvbnRpbnVhbGx5LCBzbyB0aGlzIG1heSBhbHNvIGhlbHAgdG8gaW1wcm92ZSB0aGUNCgk+ID4g
Y29kZS4NCgk+ID4NCgk+ID4gVGhlIFhNTCBsb29rcyBPSy4NCgk+ID4NCgk+ID4gUmVnYXJkcywN
Cgk+ID4gUm9kDQoJPiA+DQoJPiA+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCgk+ID4g
RnJvbTogIkN1cnRuZXkgSmFjb2JzIiA8Yy5jdXJ0bmV5amFjb2JzQGNvbWNhc3QubmV0Pg0KCT4g
PiBUbzogPHNwcmluZ2ZyYW1ld29yay11c2VyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldD4NCgk+ID4g
U2VudDogU2F0dXJkYXksIEp1bHkgMTIsIDIwMDMgNzozOCBBTQ0KCT4gPiBTdWJqZWN0OiBbU3By
aW5nZnJhbWV3b3JrLXVzZXJdIFByb3h5IGJlYW4gY29uZmlndXJhdGlvbiBIZWxwISEhIQ0KCT4g
Pg0KCT4gPiA+IElzIGFueW9uZSBvdXQgdGhlcmU/DQoJPiA+ID4NCgk+ID4gPiBJIGFtIGhhdmlu
ZyBzb21lIHByb2JsZW1zIHRyeWluZyB0byBjb25maWd1cmUgYSBwcm94eSBiZWFuLiBUaGVyZSBz
ZWVtDQoJdG8NCgk+ID4NCgk+ID4gYmUgYQ0KCT4gPg0KCT4gPiA+IHBhcnNpbmcgZXJyb3IuIEkg
ZG9uJ3QgdW5kZXJzdGFuZCB3aHkuIFRoZSBmb2xsb3dpbmcgaXMgdGhlIG9mZmVuZGluZw0KCT4g
PiA+IGNvbmZpZ3VyYXRpb246DQoJPiA+ID4NCgk+ID4gPiAgPGJlYW4gaWQ9IlJvc3RlciINCgk+
ID4gPg0KCWNsYXNzPSJjb20uaW50ZXJmYWNlMjEuZWpiLmFjY2Vzcy5Mb2NhbFN0YXRlbGVzc1Nl
c3Npb25Qcm94eUZhY3RvcnlCZWFuIj4NCgk+ID4gPiAgICAgICA8cHJvcGVydHkNCgk+ID4NCgk+
ID4NCgluYW1lPSJidXNpbmVzc0ludGVyZmFjZSI+PHZhbHVlPmNvbS5qYWNvYnMuc2VzbS5yb3N0
ZXIuUm9zdGVyPC92YWx1ZT48L3Byb3ANCgk+ID5lIHJ0eT4NCgk+ID4NCgk+ID4gPiAgICAgICA8
cHJvcGVydHkNCgluYW1lPSJqbmRpTmFtZSI+PHZhbHVlPmNtcC9Sb3N0ZXJFSkI8L3ZhbHVlPjwv
cHJvcGVydHk+DQoJPiA+ID4gICAgPC9iZWFuPg0KCT4gPiA+DQoJPiA+ID4NCgk+ID4gPiBJZiBJ
IGNvbW1lbnQgdGhlIGFib3ZlIHNlY3Rpb24sIG15IGFwcGxpY2F0aW9uIGxvYWRzIHVwIGZpbmUu
DQoJPiA+ID4NCgk+ID4gPiBBbnkgc3VnZ2VzdGlvbnMvYXNzaXN0YW5jZSB3b3VsZCBiZSBncmVh
dGx5IGFwcHJlY2lhdGVkLg0KCT4gPiA+DQoJPiA+ID4gX0NKDQoJPiA+ID4NCgk+ID4gPg0KCT4g
PiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCgk+ID4gPiBUaGlzIFNGLk5ldCBlbWFpbCBzcG9uc29yZWQgYnk6IFBhcmFzb2Z0DQoJPiA+
ID4gRXJyb3IgcHJvb2YgV2ViIGFwcHMsIGF1dG9tYXRlIHRlc3RpbmcgJiBtb3JlLg0KCT4gPiA+
IERvd25sb2FkICYgZXZhbCBXZWJLaW5nIGFuZCBnZXQgYSBmcmVlIGJvb2suDQoJPiA+ID4gd3d3
LnBhcmFzb2Z0LmNvbS9idWxsZXRwcm9vZmFwcHMxDQoJPiA+ID4gX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgk+ID4gPiBTcHJpbmdmcmFtZXdvcmstdXNl
ciBtYWlsaW5nIGxpc3QNCgk+ID4gPiBTcHJpbmdmcmFtZXdvcmstdXNlckBsaXN0cy5zb3VyY2Vm
b3JnZS5uZXQNCgk+ID4gPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0
aW5mby9zcHJpbmdmcmFtZXdvcmstdXNlcg0KCT4gPg0KCT4gPiAtLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJPiA+IFRoaXMgU0YuTmV0IGVt
YWlsIHNwb25zb3JlZCBieTogUGFyYXNvZnQNCgk+ID4gRXJyb3IgcHJvb2YgV2ViIGFwcHMsIGF1
dG9tYXRlIHRlc3RpbmcgJiBtb3JlLg0KCT4gPiBEb3dubG9hZCAmIGV2YWwgV2ViS2luZyBhbmQg
Z2V0IGEgZnJlZSBib29rLg0KCT4gPiB3d3cucGFyYXNvZnQuY29tL2J1bGxldHByb29mYXBwczEN
Cgk+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgk+
ID4gU3ByaW5nZnJhbWV3b3JrLXVzZXIgbWFpbGluZyBsaXN0DQoJPiA+IFNwcmluZ2ZyYW1ld29y
ay11c2VyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KCT4gPiBodHRwczovL2xpc3RzLnNvdXJjZWZv
cmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstdXNlcg0KCT4NCgkNCgkNCgkN
CgkNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQoJVGhpcyBTRi5OZXQgZW1haWwgc3BvbnNvcmVkIGJ5OiBQYXJhc29mdA0KCUVycm9yIHBy
b29mIFdlYiBhcHBzLCBhdXRvbWF0ZSB0ZXN0aW5nICYgbW9yZS4NCglEb3dubG9hZCAmIGV2YWwg
V2ViS2luZyBhbmQgZ2V0IGEgZnJlZSBib29rLg0KCXd3dy5wYXJhc29mdC5jb20vYnVsbGV0cHJv
b2ZhcHBzMQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQoJU3ByaW5nZnJhbWV3b3JrLXVzZXIgbWFpbGluZyBsaXN0DQoJU3ByaW5nZnJhbWV3b3JrLXVz
ZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQv
bGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3JrLXVzZXINCgkNCg0KThhIU1t7asq0SnnGttiC
ang6WnVnKilqd3rWreeiiQ0KftebV31UKX57DQpmKStKB2pny7JxB3rYtljLun56d1jPisudB2pn
DQo=

[Springframework-developer] RE: Tags using expression language?? & Petclinic

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

I'm currently checking out the sourcecode. Somehow I wasn't able to =
during the last couple of days. Well, anyway, I'll have a look into it =
and I'll let you know tomorrow...

Cheers,

Alef

-----Oorspronkelijk bericht-----
Van: Ken Krebs [mailto:kk...@kk...]
Verzonden: Saturday, July 12, 2003 6:22 PM
Aan: j=C3=BCrgen h=C3=B6ller [werk3AT]; al...@jt...
CC: spr...@li...
Onderwerp: Tags using expression language?? & Petclinic


Eliminating repetitive code in the jsp's is something I'd very much like =

to see. Alef: thanks for your contribution, it looks like it will help.

I've been in the process lately of  refactoring Petclinic's Clinic=20
implementation along with code tightening and documentation improvements =

and am just about ready to commit the changes. I WILL commit these=20
changes sometime later today. A couple of jsp's have minor changes.

Alef: If you would like to make the changes to the jsp's, please go=20
ahead. If not, I'll do it. Please let me know if you will be doing it.

Regards,
Ken
=20
j=C3=BCrgen h=C3=B6ller [werk3AT] wrote:

>I've introduced support for EL on tag attributes yesterday, already=20
>committed. Thanks for the idea and the prototype, Alef! I hope you are =
satisfied with the integration. You're very welcome to try it out :-)
>=20
>There's a new ExpressionEvaluationsUtils class now in=20
>com.interface21.web.util, taking a String argument value and parsing it =
to Object, String, int, or boolean. It will just attempt EL evaluation =
if the value starts with "${", else it will simply parse the value with =
standard means.
>=20
>All of Spring's tags use this class now for all attributes, simply=20
>delegating to the respective ExpressionEvaluationsUtils method in each =
setter. This means that all attributes still accept normal String values =
as before (like <i21:bind path=3D"person.name">), but also EL =
expressions (like <i21:bind path=3D"${bindPath}">).
>=20
>For EL evaluation, ExpressionEvaluationsUtils depends on Jakarta's JSTL =

>implementation (standard.jar). It doesn't have a runtime dependency if =
just parsing normal String values though, as it delegates EL evaluation =
to an inner class that will just get loaded in case of actual EL =
expressions. So you'll just need the Jakarta JSTL implementation in your =
classpath if you actually use EL attribute values on tags.
>=20
>BTW, our AopProxy uses a similar mechanism to avoid a runtime=20
>dependency on CGLIB. If just proxying interfaces, it will use standard =
J2SE proxies. Only if you try to proxy a class itself, it will invoke =
CGLIB by delegating to a respective inner class.
>=20
>Finally, we should adapt PetClinic to use EL expressions on its bind=20
>tags. Alef has already shown the way in the prototype that he sent. =
Ken, what do you think? Would you like Alef to do this?
>=20
>Juergen
>=20
>=20
>
>	-----Urspr=C3=BCngliche Nachricht-----=20
>	Von: j=C3=BCrgen h=C3=B6ller [werk3AT]=20
>	Gesendet: Fr 11.07.2003 08:13=20
>	An: al...@jt...; spr...@li...=20
>	Cc:=20
>	Betreff: Re: [Springframework-developer] Tags using expression=20
>language??
>=09
>=09
>
>	Alef,
>=09
>	I've just browsed your code - this looks very interesting! It makes=20
>iterating such repetitive form fields like in the petclinic much =
easier. I'll have a look at the implementation details, and if =
everything works out I'll add a clean room version to the main source =
tree promptly.
>=09
>	I wonder if we could make that work with any JSTL implementation, not=20
>just the Jakarta one, although I wouldn't mind a dependency on the =
latter for this feature.
>=09
>	Cool stuff :-)
>=09
>	Juergen
>=09
>=09
>=09
>	        -----Urspr=C3=BCngliche Nachricht-----
>	        Von: Alef Arendsen [mailto:al...@jt...]
>	        Gesendet: Di 08.07.2003 19:43
>	        An: j=C3=BCrgen h=C3=B6ller [werk3AT]; =
spr...@li...
>	        Cc:
>	        Betreff: RE: [Springframework-developer] Tags using expression =

>language??
>	      =20
>	      =20
>=09
>	        Ok, here we go...
>	      =20
>	        Like you said, at first glance, it does not look like the =
i21:bind tag
>	        needs expressionalization (hmmm, nice huh ;-). However, in the =
petclinic
>	        demo app I'm seeing a lot of input.jsps in the jsp/fields =
directory.
>	        These are things I'm hoping to solve using for instance =
EL-based tags...
>	        Attached you'll find a reworked version of the ownerForm. It =
does not
>	        use the JSPs from the fields directory anymore, but uses only =
one
>	        input.jsp that uses the bindstatus object to create the input=20
>field.
>	      =20
>	        Ok, it's still all rough and reworking the tags is a little =
bit more
>	        work than the 15 minutes I spent on it now, but maybe you're =
getting the
>	        idea.
>	      =20
>	        Consequences for adding / reworking the tags:
>	      =20
>	        1. dependency on jakarta-jstl-1.0.3 (jakarta.apache.org/taglib =
-->
>	        standard).
>	        2. dependency on jstl-1.0.3 (java.sun.com)
>	        3. In case you want to have both version in there, an =
extending class
>	        for each tag
>	        4. For each tag, a BeanInfo class
>	        5. I wasn't able to use the EvalHelper from jakarta, so I =
copied it
>	        (hmmm... not so nice, is it ;-)
>	      =20
>	        Probably I don't have time this week or something to refactor =
them to be
>	        all EL-based... Just let me know if you'd like it.
>	      =20
>	        Well, that's it for now, still discovering really cool =
features and
>	        already running out (brain)memory to think up everything I =
could do with
>	        Spring ;-)
>	      =20
>	        Cheers,
>	      =20
>	        Alef
>	      =20
>=09
>	=
N=18HS^=E9=9A=8A[){([j=1FJ=EB=A2=BAky=C6=AE^=D8=A7j+x:0Z=1Au=DA=95g*)jw`z=
=D6=9F=E7=9B=A20
>	Z(~(W(}iT)~{
>	+=D7=AFzZ)zXX*kx=1F=C5=A0u=DE=96^X(=1E~zwilq zlX)=DF=A3))~{
>	+=D7=AFzZ)
>
>?????????????????????????????????????????=D3=86+=12=17?^?=E9=9A=8A[)?{(?=
?[??=DA=AD?(~?+??=E9=AE=8A=1FY?
>=DA=A6??j?h??^??-?x?????:0?Z=1Aw?jU?l????=DD=81?Z~??n?$?=0C0???j?=1F??(?=
??W???(}?i?_???????????????????????????????????*k?x=1F???=C5=A0??=D7=AFzZ=
)z???X??X??*k?x=1F???=C5=A0??=D7=AFzZ)z???l??.?=C7=9F??=1E?w???i????+-??(=
??=1E~??{?=DE=B7?b????+-?w???k?x=1F???=C5=A0??=D7=AFzZ)
>
>
> =20
>

Re: [Springframework-developer] JavaBeans lifecycle considerations?

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

Ivan, Juergen

Some thoughts. Ivan, don't get the impression I'm negative about this area:
I just want to make sure that any additional complexity we build into the
bean factory is warranted.

> * Complete bean life cycle: parameters, initialisation, start, stop,
suspend, resume, reconfigure, dispose/destroy
> I agree that a single pair of start/stop methods should do the job, no
need for a suspend/resume. This could be modelled as a "Startable"
interface. A separate "Disposable" interface could feature a dispose method
for cleanup purposes on shutdown.
+1. Non-invasive in good Spring fashion. Only if a bean implements these
methods will they be called. No irrelevant methods to implement like
ejbActivate/ejbPassivate for SLSBs.

>
> * Beans that want to can execute on their own thread
> How is this supposed to work? The execution thread is always determined by
the caller of a bean's methods. In that respect, a bean can't execute "on
its own thread", if I understand correctly. A bean can *create* its own
threads though, either on initialization or on certain method calls. But in
any case, the main method invocation will always execute in the caller's
thread. Therefore I don't think that we need "own thread" support. Spring
simply treats such thread starters as conventional beans, initializing them
and making them available. It doesn't care if and when a bean starts and
stops new threads - that's the bean's responsibility.

You mean a bean that kicks off an asynchronous process somehow? But what
would it return to the caller? We probably do need more sophisticated thread
models for app context event listeners. At present the multicast event
listener uses the same thread as the call that created the event, allowing a
rogue listener to lock the app. It would be easy to support several options,
with this the default, as it's low overhead if people implement their
listeners properly. (Ie a listener kicks off a background thread if it needs
to).

> * Singleton/shared and not-shared beans
> * Bean pools (check-in, check-out)
>
> As you've noted, Spring already supports the first two notions. Regarding
bean pools, I'm not too convinced if they actually add value. In contrast to
EJBs, beans are extremely lightweight, the on-demand creation overhead
normally doesn't matter. Personally, I just use singleton beans, as I find
hardly any scenarios where I couldn't write a thread-safe, reusable bean.
Even when exporting remote beans via Hessian / Burlap / RMI / SOAP /
whatever, it should always be possible to write a single thread-safe bean
instance.

I agree on Juergen regarding pooling. IMHO, object pooling is overrated,
considering the efficiency of garbage collection in modern JVMs. With our
model, if people want single threaded, they can use the "prototype"
(non-shared) model. This will then be something like WebWork.

> Instance pooling would add a significant amount of overhead: There would
indeed have to be an explicit checkout and checkin, or a transparent
checkout / checkin on each method invocation, using an invocation proxy that
delegates to the actual pooled instance. That may make sense for access to
load-balanced remote services, but I really doubt the value for local
invocations. I simply don't see a need for modelling local services this
way, even if EJB's Stateless Session Beans offer such pooling for local
instances too.

Like Juergen, I'd need a lot of persuasion oin this.

> * Ability to safely reconfigure a bean that is referenced by other beans
> Reconfiguration is indeed an interesting issue, as it may need to block
the system to guarantee consistency: Various configuration changes might
depend on each other, i.e. need to be applied completely or not at all to
keep the system intact. This is somewhat similar to a classloader that
supports "hot" class reloading, like in a servlet container: Effectively, it
can't be guaranteed that updating a class won't break the system due to all
kinds of side effects. Thus, hot class reloading is mainly a development
feature, not recommended for production environments.
> For specific settings that are local to a single bean, "hot"
reconfiguration should be solvable though. For development environments, one
could simply overwrite the respective bean properties and proceed - this
would be fine in many cases, avoiding the need to restart the container. In
a concurrent production environment, this can obviously cause all kinds of
side effects. So we would need to use a lifecycle-aware proxy here,
intercepting and registering all method calls to the bean instance. In case
of an ongoing reconfiguration, the container would have to wait for all
running method calls to return while blocking all new requests, then apply
the reconfiguration, and finally allow the waiting requests to proceed.
> This sounds like a case for an AOP interceptor to me!

This is a very interesting area. Semi-coherent braindump follows.

Do we want to call additional setters on a running bean? e.g.
setRetryCount(n) to a new value? This might be appropriate in some cases,
especially for simpler things. Yet it would place constraints on beans,
implying that some metadata might be required to indicate which fields were
refreshable.

Our AOP, and your suggestions regarding interceptors, suggest the idea of
using copy-on-write in a proxy. However, this would only work with proxies,
and the synchronization could be scary. We could have as well as the simple
InvokerInterceptor (which invokes the target via reflection) a
ChangeAwareInvoker, that recognizes when it needs a new instance of the
underlying object or needs to reconfigure the underlying object, and queues
requests at that time. This would mean only a new interceptor not a major
change to the framework. It would have to know when things had changed,
however, so the BF would need to provide that. I guess the factory could
poll the underlying resource (the abstract factory could provide polling in
a storage-independent way). How would it communicate changes? Via setting
new property values on bean instances? We don't really want to detype the
changes into an update(Properties) method or the like.

How much blocking is required really depends on the app code in question.
Which means that metadata might need to be used to drive it.

>
> * Load/unload beans
>
> I guess you mean bean instances here, not bean classes, and I assume load
/ unload means invoking initialize / dispose of predefined bean instances. I
wonder what use cases you see for explicit beanFactory.load("myBeanName")
and beanFactory.unload("myBeanName") calls. When would an application
developer want to explicitly load and unload beans at runtime - maybe to
make certain exported remote services available / unavailable?

I'd like to see use cases for this.

>
> * Reload bean class (in combination with bean pools this probably means
that multiple bean versions will run in parallel at times)
> We would need own classloader hierarchies for such stuff. Basically, every
bean instance would have to be loaded in its own classloader to achieve
this. I rather consider classloader handling an issue for J2EE containers,
not for application frameworks, due to all the nasty hassles that are
involved. And as I've outlined above, this is really hard if not impossible
to handle properly in a concurrent environment, as any bean can have
dependencies on any other. How to guarantee consistency within the whole
system here?

I don't want to get into class loading, if we can possibly help it.

>
> * Persist bean configuration (not serialization, properties only)
Isn't the XML doing this?

> Why would you want to persist a bean's property values - when would you
want to load them again? Basically, the bean factory defines all property
values, e.g. in a properties or XML file. Changing values at runtime should
also occur via these files IMO, the modified file timestamp triggering a
reconfiguration of the watching factory.

That's my view. The factory should be able to compute the minimum change
set.

> * Finally, a container needs to be written which would allow access to all
beans and their configuration from the outside, plus options to load/unload
beans, reconfigure them, inspect them and so on.
> Basically, a Spring BeanFactory resp. ApplicationContext matches that
role, although these interfaces represent a bean user API, avoiding bean
definition details. Implementation classes like AbstractBeanFactory,
ListableBeanFactoryImpl, and AbstractApplicationContext offer access to such
SPI details too. With some added methods e.g. for loading/unloading,
sufficient control and inspection capabilities should be available.

What about JMX? So long as it could be done without forcing JMX complexity
on user code.

Regards,
Rod

Re: [Springframework-developer] JavaBeans lifecycle considerations?

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

SGkgSXZhbiwNCiANCkludGVyZXN0aW5nIHN0dWZmISBXZSBkbyBjb21wZXRlIHdpdGggYm90aCBB
dmFsb24gYW5kIFBpY29Db250YWluZXIgaW4gdGhhdCByZXNwZWN0LCBhbHRob3VnaCBBdmFsb24g
aXMgZmFyIG1vcmUgY29tcGxleCB0aGFuIFBpY29Db250YWluZXIgZnJvbSBteSBwb2ludCBvZiB2
aWV3LiBJIGRpZG4ndCBrbm93IGFib3V0IEhpdmVNaW5kIHlldCwgaXQgZG9lc24ndCBzZWVtIHBh
cnRpY3VsYXJseSBjb252aW5jaW5nIHRob3VnaC4gQW55d2F5LCBJIGNvbnNpZGVyIFNwcmluZydz
IGJlYW4tY2VudHJpYyBhcHByb2FjaCBzbyBzaW1wbGUsIG5vbi1pbnRydXNpdmUsIGFuZCBwb3dl
cmZ1bCB0aGF0IGl0IGlzIHJlYWxseSBoYXJkIHRvIGJlYXQgOi0pDQogDQpDb25jZXJuaW5nIHlv
dXIgcmVxdWlyZW1lbnRzOg0KIA0KKiBDb21wbGV0ZSBiZWFuIGxpZmUgY3ljbGU6IHBhcmFtZXRl
cnMsIGluaXRpYWxpc2F0aW9uLCBzdGFydCwgc3RvcCwgc3VzcGVuZCwgcmVzdW1lLCByZWNvbmZp
Z3VyZSwgZGlzcG9zZS9kZXN0cm95DQoNCkkgYWdyZWUgdGhhdCBhIHNpbmdsZSBwYWlyIG9mIHN0
YXJ0L3N0b3AgbWV0aG9kcyBzaG91bGQgZG8gdGhlIGpvYiwgbm8gbmVlZCBmb3IgYSBzdXNwZW5k
L3Jlc3VtZS4gVGhpcyBjb3VsZCBiZSBtb2RlbGxlZCBhcyBhICJTdGFydGFibGUiIGludGVyZmFj
ZS4gQSBzZXBhcmF0ZSAiRGlzcG9zYWJsZSIgaW50ZXJmYWNlIGNvdWxkIGZlYXR1cmUgYSBkaXNw
b3NlIG1ldGhvZCBmb3IgY2xlYW51cCBwdXJwb3NlcyBvbiBzaHV0ZG93bi4NCg0KKiBCZWFucyB0
aGF0IHdhbnQgdG8gY2FuIGV4ZWN1dGUgb24gdGhlaXIgb3duIHRocmVhZA0KDQpIb3cgaXMgdGhp
cyBzdXBwb3NlZCB0byB3b3JrPyBUaGUgZXhlY3V0aW9uIHRocmVhZCBpcyBhbHdheXMgZGV0ZXJt
aW5lZCBieSB0aGUgY2FsbGVyIG9mIGEgYmVhbidzIG1ldGhvZHMuIEluIHRoYXQgcmVzcGVjdCwg
YSBiZWFuIGNhbid0IGV4ZWN1dGUgIm9uIGl0cyBvd24gdGhyZWFkIiwgaWYgSSB1bmRlcnN0YW5k
IGNvcnJlY3RseS4gQSBiZWFuIGNhbiAqY3JlYXRlKiBpdHMgb3duIHRocmVhZHMgdGhvdWdoLCBl
aXRoZXIgb24gaW5pdGlhbGl6YXRpb24gb3Igb24gY2VydGFpbiBtZXRob2QgY2FsbHMuIEJ1dCBp
biBhbnkgY2FzZSwgdGhlIG1haW4gbWV0aG9kIGludm9jYXRpb24gd2lsbCBhbHdheXMgZXhlY3V0
ZSBpbiB0aGUgY2FsbGVyJ3MgdGhyZWFkLiBUaGVyZWZvcmUgSSBkb24ndCB0aGluayB0aGF0IHdl
IG5lZWQgIm93biB0aHJlYWQiIHN1cHBvcnQuIFNwcmluZyBzaW1wbHkgdHJlYXRzIHN1Y2ggdGhy
ZWFkIHN0YXJ0ZXJzIGFzIGNvbnZlbnRpb25hbCBiZWFucywgaW5pdGlhbGl6aW5nIHRoZW0gYW5k
IG1ha2luZyB0aGVtIGF2YWlsYWJsZS4gSXQgZG9lc24ndCBjYXJlIGlmIGFuZCB3aGVuIGEgYmVh
biBzdGFydHMgYW5kIHN0b3BzIG5ldyB0aHJlYWRzIC0gdGhhdCdzIHRoZSBiZWFuJ3MgcmVzcG9u
c2liaWxpdHkuDQoNCiogU2luZ2xldG9uL3NoYXJlZCBhbmQgbm90LXNoYXJlZCBiZWFucw0KKiBC
ZWFuIHBvb2xzIChjaGVjay1pbiwgY2hlY2stb3V0KQ0KDQpBcyB5b3UndmUgbm90ZWQsIFNwcmlu
ZyBhbHJlYWR5IHN1cHBvcnRzIHRoZSBmaXJzdCB0d28gbm90aW9ucy4gUmVnYXJkaW5nIGJlYW4g
cG9vbHMsIEknbSBub3QgdG9vIGNvbnZpbmNlZCBpZiB0aGV5IGFjdHVhbGx5IGFkZCB2YWx1ZS4g
SW4gY29udHJhc3QgdG8gRUpCcywgYmVhbnMgYXJlIGV4dHJlbWVseSBsaWdodHdlaWdodCwgdGhl
IG9uLWRlbWFuZCBjcmVhdGlvbiBvdmVyaGVhZCBub3JtYWxseSBkb2Vzbid0IG1hdHRlci4gUGVy
c29uYWxseSwgSSBqdXN0IHVzZSBzaW5nbGV0b24gYmVhbnMsIGFzIEkgZmluZCBoYXJkbHkgYW55
IHNjZW5hcmlvcyB3aGVyZSBJIGNvdWxkbid0IHdyaXRlIGEgdGhyZWFkLXNhZmUsIHJldXNhYmxl
IGJlYW4uIEV2ZW4gd2hlbiBleHBvcnRpbmcgcmVtb3RlIGJlYW5zIHZpYSBIZXNzaWFuIC8gQnVy
bGFwIC8gUk1JIC8gU09BUCAvIHdoYXRldmVyLCBpdCBzaG91bGQgYWx3YXlzIGJlIHBvc3NpYmxl
IHRvIHdyaXRlIGEgc2luZ2xlIHRocmVhZC1zYWZlIGJlYW4gaW5zdGFuY2UuDQogDQpJbnN0YW5j
ZSBwb29saW5nIHdvdWxkIGFkZCBhIHNpZ25pZmljYW50IGFtb3VudCBvZiBvdmVyaGVhZDogVGhl
cmUgd291bGQgaW5kZWVkIGhhdmUgdG8gYmUgYW4gZXhwbGljaXQgY2hlY2tvdXQgYW5kIGNoZWNr
aW4sIG9yIGEgdHJhbnNwYXJlbnQgY2hlY2tvdXQgLyBjaGVja2luIG9uIGVhY2ggbWV0aG9kIGlu
dm9jYXRpb24sIHVzaW5nIGFuIGludm9jYXRpb24gcHJveHkgdGhhdCBkZWxlZ2F0ZXMgdG8gdGhl
IGFjdHVhbCBwb29sZWQgaW5zdGFuY2UuIFRoYXQgbWF5IG1ha2Ugc2Vuc2UgZm9yIGFjY2VzcyB0
byBsb2FkLWJhbGFuY2VkIHJlbW90ZSBzZXJ2aWNlcywgYnV0IEkgcmVhbGx5IGRvdWJ0IHRoZSB2
YWx1ZSBmb3IgbG9jYWwgaW52b2NhdGlvbnMuIEkgc2ltcGx5IGRvbid0IHNlZSBhIG5lZWQgZm9y
IG1vZGVsbGluZyBsb2NhbCBzZXJ2aWNlcyB0aGlzIHdheSwgZXZlbiBpZiBFSkIncyBTdGF0ZWxl
c3MgU2Vzc2lvbiBCZWFucyBvZmZlciBzdWNoIHBvb2xpbmcgZm9yIGxvY2FsIGluc3RhbmNlcyB0
b28uDQogDQpJIGNvbnNpZGVyIFNMU0IgbXVsdGktdGhyZWFkaW5nIHN1cHBvcnQgc29tZXdoYXQg
d29ydGhsZXNzLCBpLmUuIHRoYXQgdGhlcmUgd2lsbCBhbHdheXMgYmUganVzdCBvbmUgY29uY3Vy
cmVudCBpbnZvY2F0aW9uIG9uIGFueSBnaXZlbiBpbnN0YW5jZSwgZ2l2aW5nIHJpc2UgdG8gdGhl
IG5lZWQgZm9yIGluc3RhbmNlIHBvb2xzIHRvIHN1cHBvcnQgbXVsdGlwbGUgY29uY3VycmVudCBp
bnZvY2F0aW9ucy4gVGhhdCBqdXN0IG1ha2VzIHNlbnNlIHdoZW4gdGhlcmUgYXJlIG5vbi10aHJl
YWQtc2FmZSBpbnN0YW5jZSB2YXJpYWJsZXMgLSBidXQgSSBoYXZlbid0IHNlZW4gY29udmluY2lu
ZyBleGFtcGxlcyBmb3Igc3VjaCByZXNvdXJjZXMuIEVpdGhlciB5b3UgY2FuIHNoYXJlIHRoZW0g
d2l0aG91dCBoYXNzbGUsIGxpa2UgRGF0YVNvdXJjZXMgZXRjLCBvciB5b3UgY2FuIGNyZWF0ZSB0
aGVtIHdpdGhpbiBlYWNoIG1ldGhvZCBpbnZvY2F0aW9uLiBJbiBib3RoIGNhc2VzLCB0aGUgYmVh
biBpbnN0YW5jZSBpcyBwZXJmZWN0bHkgdGhyZWFkLXNhZmUsIG11bHRpcGxlIGNvbmN1cnJlbnQg
aW52b2NhdGlvbnMgYXJlIGZpbmUgLSB0aHVzIG5vIG5lZWQgZm9yIHBvb2xpbmcuIFNlcnZsZXRz
IGFyZSBhIGdvb2QgZXhhbXBsZSB0b286IFNpbmdsZVRocmVhZE1vZGVsIGhhcyBldmVuIGJlZW4g
ZGVwcmVjYXRlZCB0aGVyZSwgaW4gU2VydmxldCAyLjQuDQogDQoqIEFiaWxpdHkgdG8gc2FmZWx5
IHJlY29uZmlndXJlIGEgYmVhbiB0aGF0IGlzIHJlZmVyZW5jZWQgYnkgb3RoZXIgYmVhbnMNCiAN
ClJlY29uZmlndXJhdGlvbiBpcyBpbmRlZWQgYW4gaW50ZXJlc3RpbmcgaXNzdWUsIGFzIGl0IG1h
eSBuZWVkIHRvIGJsb2NrIHRoZSBzeXN0ZW0gdG8gZ3VhcmFudGVlIGNvbnNpc3RlbmN5OiBWYXJp
b3VzIGNvbmZpZ3VyYXRpb24gY2hhbmdlcyBtaWdodCBkZXBlbmQgb24gZWFjaCBvdGhlciwgaS5l
LiBuZWVkIHRvIGJlIGFwcGxpZWQgY29tcGxldGVseSBvciBub3QgYXQgYWxsIHRvIGtlZXAgdGhl
IHN5c3RlbSBpbnRhY3QuIFRoaXMgaXMgc29tZXdoYXQgc2ltaWxhciB0byBhIGNsYXNzbG9hZGVy
IHRoYXQgc3VwcG9ydHMgImhvdCIgY2xhc3MgcmVsb2FkaW5nLCBsaWtlIGluIGEgc2VydmxldCBj
b250YWluZXI6IEVmZmVjdGl2ZWx5LCBpdCBjYW4ndCBiZSBndWFyYW50ZWVkIHRoYXQgdXBkYXRp
bmcgYSBjbGFzcyB3b24ndCBicmVhayB0aGUgc3lzdGVtIGR1ZSB0byBhbGwga2luZHMgb2Ygc2lk
ZSBlZmZlY3RzLiBUaHVzLCBob3QgY2xhc3MgcmVsb2FkaW5nIGlzIG1haW5seSBhIGRldmVsb3Bt
ZW50IGZlYXR1cmUsIG5vdCByZWNvbW1lbmRlZCBmb3IgcHJvZHVjdGlvbiBlbnZpcm9ubWVudHMu
DQogDQpGb3Igc3BlY2lmaWMgc2V0dGluZ3MgdGhhdCBhcmUgbG9jYWwgdG8gYSBzaW5nbGUgYmVh
biwgImhvdCIgcmVjb25maWd1cmF0aW9uIHNob3VsZCBiZSBzb2x2YWJsZSB0aG91Z2guIEZvciBk
ZXZlbG9wbWVudCBlbnZpcm9ubWVudHMsIG9uZSBjb3VsZCBzaW1wbHkgb3ZlcndyaXRlIHRoZSBy
ZXNwZWN0aXZlIGJlYW4gcHJvcGVydGllcyBhbmQgcHJvY2VlZCAtIHRoaXMgd291bGQgYmUgZmlu
ZSBpbiBtYW55IGNhc2VzLCBhdm9pZGluZyB0aGUgbmVlZCB0byByZXN0YXJ0IHRoZSBjb250YWlu
ZXIuIEluIGEgY29uY3VycmVudCBwcm9kdWN0aW9uIGVudmlyb25tZW50LCB0aGlzIGNhbiBvYnZp
b3VzbHkgY2F1c2UgYWxsIGtpbmRzIG9mIHNpZGUgZWZmZWN0cy4gU28gd2Ugd291bGQgbmVlZCB0
byB1c2UgYSBsaWZlY3ljbGUtYXdhcmUgcHJveHkgaGVyZSwgaW50ZXJjZXB0aW5nIGFuZCByZWdp
c3RlcmluZyBhbGwgbWV0aG9kIGNhbGxzIHRvIHRoZSBiZWFuIGluc3RhbmNlLiBJbiBjYXNlIG9m
IGFuIG9uZ29pbmcgcmVjb25maWd1cmF0aW9uLCB0aGUgY29udGFpbmVyIHdvdWxkIGhhdmUgdG8g
d2FpdCBmb3IgYWxsIHJ1bm5pbmcgbWV0aG9kIGNhbGxzIHRvIHJldHVybiB3aGlsZSBibG9ja2lu
ZyBhbGwgbmV3IHJlcXVlc3RzLCB0aGVuIGFwcGx5IHRoZSByZWNvbmZpZ3VyYXRpb24sIGFuZCBm
aW5hbGx5IGFsbG93IHRoZSB3YWl0aW5nIHJlcXVlc3RzIHRvIHByb2NlZWQuDQogDQpUaGlzIHNv
dW5kcyBsaWtlIGEgY2FzZSBmb3IgYW4gQU9QIGludGVyY2VwdG9yIHRvIG1lIQ0KDQoqIExvYWQv
dW5sb2FkIGJlYW5zDQogDQpJIGd1ZXNzIHlvdSBtZWFuIGJlYW4gaW5zdGFuY2VzIGhlcmUsIG5v
dCBiZWFuIGNsYXNzZXMsIGFuZCBJIGFzc3VtZSBsb2FkIC8gdW5sb2FkIG1lYW5zIGludm9raW5n
IGluaXRpYWxpemUgLyBkaXNwb3NlIG9mIHByZWRlZmluZWQgYmVhbiBpbnN0YW5jZXMuIEkgd29u
ZGVyIHdoYXQgdXNlIGNhc2VzIHlvdSBzZWUgZm9yIGV4cGxpY2l0IGJlYW5GYWN0b3J5LmxvYWQo
Im15QmVhbk5hbWUiKSBhbmQgYmVhbkZhY3RvcnkudW5sb2FkKCJteUJlYW5OYW1lIikgY2FsbHMu
IFdoZW4gd291bGQgYW4gYXBwbGljYXRpb24gZGV2ZWxvcGVyIHdhbnQgdG8gZXhwbGljaXRseSBs
b2FkIGFuZCB1bmxvYWQgYmVhbnMgYXQgcnVudGltZSAtIG1heWJlIHRvIG1ha2UgY2VydGFpbiBl
eHBvcnRlZCByZW1vdGUgc2VydmljZXMgYXZhaWxhYmxlIC8gdW5hdmFpbGFibGU/DQoNCiogUmVs
b2FkIGJlYW4gY2xhc3MgKGluIGNvbWJpbmF0aW9uIHdpdGggYmVhbiBwb29scyB0aGlzIHByb2Jh
Ymx5IG1lYW5zIHRoYXQgbXVsdGlwbGUgYmVhbiB2ZXJzaW9ucyB3aWxsIHJ1biBpbiBwYXJhbGxl
bCBhdCB0aW1lcykNCiANCldlIHdvdWxkIG5lZWQgb3duIGNsYXNzbG9hZGVyIGhpZXJhcmNoaWVz
IGZvciBzdWNoIHN0dWZmLiBCYXNpY2FsbHksIGV2ZXJ5IGJlYW4gaW5zdGFuY2Ugd291bGQgaGF2
ZSB0byBiZSBsb2FkZWQgaW4gaXRzIG93biBjbGFzc2xvYWRlciB0byBhY2hpZXZlIHRoaXMuIEkg
cmF0aGVyIGNvbnNpZGVyIGNsYXNzbG9hZGVyIGhhbmRsaW5nIGFuIGlzc3VlIGZvciBKMkVFIGNv
bnRhaW5lcnMsIG5vdCBmb3IgYXBwbGljYXRpb24gZnJhbWV3b3JrcywgZHVlIHRvIGFsbCB0aGUg
bmFzdHkgaGFzc2xlcyB0aGF0IGFyZSBpbnZvbHZlZC4gQW5kIGFzIEkndmUgb3V0bGluZWQgYWJv
dmUsIHRoaXMgaXMgcmVhbGx5IGhhcmQgaWYgbm90IGltcG9zc2libGUgdG8gaGFuZGxlIHByb3Bl
cmx5IGluIGEgY29uY3VycmVudCBlbnZpcm9ubWVudCwgYXMgYW55IGJlYW4gY2FuIGhhdmUgZGVw
ZW5kZW5jaWVzIG9uIGFueSBvdGhlci4gSG93IHRvIGd1YXJhbnRlZSBjb25zaXN0ZW5jeSB3aXRo
aW4gdGhlIHdob2xlIHN5c3RlbSBoZXJlPw0KDQoqIFBlcnNpc3QgYmVhbiBjb25maWd1cmF0aW9u
IChub3Qgc2VyaWFsaXphdGlvbiwgcHJvcGVydGllcyBvbmx5KQ0KIA0KV2h5IHdvdWxkIHlvdSB3
YW50IHRvIHBlcnNpc3QgYSBiZWFuJ3MgcHJvcGVydHkgdmFsdWVzIC0gd2hlbiB3b3VsZCB5b3Ug
d2FudCB0byBsb2FkIHRoZW0gYWdhaW4/IEJhc2ljYWxseSwgdGhlIGJlYW4gZmFjdG9yeSBkZWZp
bmVzIGFsbCBwcm9wZXJ0eSB2YWx1ZXMsIGUuZy4gaW4gYSBwcm9wZXJ0aWVzIG9yIFhNTCBmaWxl
LiBDaGFuZ2luZyB2YWx1ZXMgYXQgcnVudGltZSBzaG91bGQgYWxzbyBvY2N1ciB2aWEgdGhlc2Ug
ZmlsZXMgSU1PLCB0aGUgbW9kaWZpZWQgZmlsZSB0aW1lc3RhbXAgdHJpZ2dlcmluZyBhIHJlY29u
ZmlndXJhdGlvbiBvZiB0aGUgd2F0Y2hpbmcgZmFjdG9yeS4NCg0KKiBGaW5hbGx5LCBhIGNvbnRh
aW5lciBuZWVkcyB0byBiZSB3cml0dGVuIHdoaWNoIHdvdWxkIGFsbG93IGFjY2VzcyB0byBhbGwg
YmVhbnMgYW5kIHRoZWlyIGNvbmZpZ3VyYXRpb24gZnJvbSB0aGUgb3V0c2lkZSwgcGx1cyBvcHRp
b25zIHRvIGxvYWQvdW5sb2FkIGJlYW5zLCByZWNvbmZpZ3VyZSB0aGVtLCBpbnNwZWN0IHRoZW0g
YW5kIHNvIG9uLg0KIA0KQmFzaWNhbGx5LCBhIFNwcmluZyBCZWFuRmFjdG9yeSByZXNwLiBBcHBs
aWNhdGlvbkNvbnRleHQgbWF0Y2hlcyB0aGF0IHJvbGUsIGFsdGhvdWdoIHRoZXNlIGludGVyZmFj
ZXMgcmVwcmVzZW50IGEgYmVhbiB1c2VyIEFQSSwgYXZvaWRpbmcgYmVhbiBkZWZpbml0aW9uIGRl
dGFpbHMuIEltcGxlbWVudGF0aW9uIGNsYXNzZXMgbGlrZSBBYnN0cmFjdEJlYW5GYWN0b3J5LCBM
aXN0YWJsZUJlYW5GYWN0b3J5SW1wbCwgYW5kIEFic3RyYWN0QXBwbGljYXRpb25Db250ZXh0IG9m
ZmVyIGFjY2VzcyB0byBzdWNoIFNQSSBkZXRhaWxzIHRvby4gV2l0aCBzb21lIGFkZGVkIG1ldGhv
ZHMgZS5nLiBmb3IgbG9hZGluZy91bmxvYWRpbmcsIHN1ZmZpY2llbnQgY29udHJvbCBhbmQgaW5z
cGVjdGlvbiBjYXBhYmlsaXRpZXMgc2hvdWxkIGJlIGF2YWlsYWJsZS4NCiANClJlZ2FyZHMsDQpK
dWVyZ2VuDQo=