springframework-developer — Spring Framework developers list

[Springframework-developer] AppCtx refresh not threadsafe

[Rob B. <rob...@ve...>]

Hello all,

The various implementations of the ConfigurableApplicationContext refresh() method do not appear to be threadsafe.  I check M4 code base, but it looks like it was never threadsafe in any of the previous implementations either (M2 wasn't threadsafe either).

Let's use XmlWebApplicationContext as an example.

First of all the refresh method in AbstractApplicationContext (a super class of XmlWebApplicationContext) should probably be syncronized so that two threads cannot call refresh at the same time (potential race condition in configuring two bean factories simultaneously).

Secondly if refresh is called, any thread which calls getBeanFactory() before refresh is completed may not get a fully configured bean factory.

AbstractApplicationContext.refresh() calls AbstractXmlApplicationContext.refreshBeanFactory(), from this point on until the refresh method is finished any calls to getBeanFactory are returning a bean factory that is in the process of being configured, but is not yet ready for use in the application.  AbstractApplicationContext.refresh() then takes advantage of that fact to continue the processing needed to complete the configuration of the bean factory.

A non-threadsafe implementation of ConfigurableApplicationContext may not be a problem in a GUI application where we have complete control over threads, but should not be used in an application / environment (Like a servlet / ejb container) where we don't.  Everything is threadsafe as long as your app never needs to call refresh(), but then that requires you to restart your web app to change any configuration properties.

One potential way to fix the threading issue may be to add a few methods to ConfigurableApplicationContext.

1) getLoadingBeanFactory() - Returns the bean factory that is in the process of being loaded.
2) beanFactoryLoaded() - Informs sub-classes that the bean factory configuration is complete and they should now return the new bean factory in any requests to getBeanFactory()

Modify all code that calls getBeanFactory() during loading to call getLoadingBeanFactory() instead.
Modify AbstractXmlApplicationContext to have both a loading & live bean factory class variables.  When beanFactoryLoaded() is called then live = loading, loading = null.

An alternative is to modify refreshBeanFactory() to return the bean factory object it created instead of setting this.beanfactory.  Then refresh() in AbstractApplicationContext should be modified to use the returned bean factory, along with all the methods it calls.  The method beanFactoryLoaded() method could be implemented to accept a parameter instead of no parameter as indicated above.  Thus it would be beanFactoryLoaded(ConfigurableListableBeanFactory newBeanFactory).  AbstractXmlApplicationContext would then know to use the new bean factory that was passed from that point on, and getLoadingBeanFactory() would not be needed.

Later
Rob

Re: [Springframework-developer] Security SPI: Access Control

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

Yes, security is an isue that has come up several times in the spring-user
list. Someone proposed a pretty comprehensive solution.

Security will be considered as a new feature in Spring 1.1.

Thanks for the suggestions.

Rod

----- Original Message -----
From: "Double Delight" <dou...@ya...>
To: <spr...@li...>
Sent: Sunday, January 11, 2004 10:39 PM
Subject: [Springframework-developer] Security SPI: Access Control


> The Spring Security SPI would look like:
> --  Authentication:  Pluggable providers for SAML,
> WS-Security,  ProjectLiberty, etc.
> --  Access Control:  Pluggable providers for XACML,
> RBAC (Roles Based Access Control)
>
>
> Since Authentication has been done many times, lets
> focus on providing a standards based Access Control
> solution.  After much looking around, XACML seems to
> be the standard and they have a RBAC profile also.
>
> XACML Links:
> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
>
>
> OpenSource XACML engine:
> http://sunxacml.sourceforge.net/
>
> Research proposal for including XACML in J2SE:
> http://research.sun.com/projects/xacml/J2SEPolicyProvider.html
>
>
> Most importantly, RBAC implemented with XACML:
>
http://www.oasis-open.org/committees/download.php/2405/wd-xacml-rbac-profile
-01.doc
>
>
> Cheers,
> -- DD
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
> http://hotjobs.sweepstakes.yahoo.com/signingbonus
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] Security SPI: Access Control

[Double D. <dou...@ya...>]

The Spring Security SPI would look like:
--  Authentication:  Pluggable providers for SAML,
WS-Security,  ProjectLiberty, etc.
--  Access Control:  Pluggable providers for XACML,
RBAC (Roles Based Access Control)


Since Authentication has been done many times, lets
focus on providing a standards based Access Control
solution.  After much looking around, XACML seems to
be the standard and they have a RBAC profile also.

XACML Links:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml


OpenSource XACML engine:
http://sunxacml.sourceforge.net/ 

Research proposal for including XACML in J2SE:
http://research.sun.com/projects/xacml/J2SEPolicyProvider.html


Most importantly, RBAC implemented with XACML:
http://www.oasis-open.org/committees/download.php/2405/wd-xacml-rbac-profile-01.doc


Cheers,
-- DD


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

[Springframework-developer] Security SPI for Spring

[Double D. <dou...@ya...>]

Java has done a good job creating a pluggable JNDI
SPI:
http://java.sun.com/products/jndi/serviceproviders.html


But, Java does not have a pluggable Security SPI.
(JAAS is not it).

So, various J2EE vendors (see links below) have gone
on to create their own Security SPI.

However, none of the opensource Java frameworks
include a Security SPI.

I am hoping that Spring will provide a pluggable
Security SPI:
--  Authentication:  Pluggable providers for SAML,
WS-Security,  ProjectLiberty, etc.
--  Access Control:  Pluggable providers for XACML,
RBAC (Roles Based Access Control)

For the benefit of all Spring users, how would one go
about creating this?  Any Spring+security experts who
can lead this effort?

Cheers,
--  DD


WebLogic has the most comprehensive Security SPI:
http://e-docs.bea.com/wls/docs81/javadocs/weblogic/security/spi/package-summary.html

Borland Security SPI (J2EE and CORBA):
http://info.borland.com/techpubs/bes/dusecurityapijava.html


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

[Springframework-developer] PROPOGATION_REQUIRESNEW

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

What would be involved in supporting PROPOGATION_REQUIRESNEW, similar to 
an EJB setting of RequiresNew?

While J2EE doesn't support nested transactions for EJBs (although 
JTS/JTA may or may not) EJBs do support the RequiresNew setting, which 
is supposed to 'suspend' the current transaction and start a new one, 
the termination of which will either commit or rollback the new 
transaction, without affecting the enclosing one.

Now if you are dealing with a UserTransaction object, and call begin(), 
my understanding is that you will either get a real nested transaction 
if the transaction manager supports nested transactions, or an exception 
if it doesn't (which presumably most transaction managers in most 
containers will not).

So I am curious how EJB containers implement RequiresNew. I presume that 
as of the RequiresNew, they associate an entirely new transaction 
manager for the purposes of that EJB/thread. As such, it would be 
impossible for Spring to do the same thing when working with a JTA 
UserTransaction from JNDI, since it is not the container actually 
managing the transaction manager. I presume if Spring itself were to 
completely manage transactions (ie it was the transaction manager) then 
it would not be an issue to simulate the EJB behaviour.

Part of my reason for bringing up this topic is that people converting 
code from EJBs often have declarative transactions with RequiresNew. Now 
a lot of the time it makes no difference if they switch to Requires (and 
in fact they used Requires vs. RequiresNew due to the restrictive EJB 
level locking implemented by most containers), but some of the time, for 
handling things like logging, etc., RequiresNew would be desirable.

Anybody care to comment?

Regards
Colin

[Springframework-developer] Survey: Motivations to Contribute

[Ralph S. <a95...@un...>]

Hi all!

I'm doing a research project on the motives of free software / open source 
software developers. This survey follows a somewhat different approach than 
some earlier studies and tries to incorporate concepts of social 
psychology to better understand the internal motivation of developers.  

The questionnaire consists of 44 questions which should be scored on a scale
from 1 to 7. According to test runs, completion of the questionnaire should 
take about 6 minutes. No registration required.  

 
The questionnaire and more information about the survey can be found here:

*** http://foss-survey.at.tf ***
  
The survey will be online until the end of January. I hope to have the results
online by mid February. If you want to be notified, please enter
your email address in the appropriate box. 

If you have questions or comments about this survey, please CC me or email me
directly, because I won't be able to follow all the lists/forums.  

Thank you. Your help is greatly appreciated.

ralph

[Springframework-developer] Row limit in MappingSQLQueryWithParameters

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

Hi all,

I'm doing some work with a client who I've persuaded to use Spring (they 
just ordered another 10 copies of Rod's book :) and I've found I'm 
writing a lot of search type queries - where the user enters search 
criteria and I build a query based on them. If the criteria are too 
vague, the amount of returned data could potentially be horrendous, so I 
want to be able to set a limit on the number of rows and throw an 
exception if the rowcount goes above it. It occurred to me that the 
checking could be added to the framework with a few minor changes. It 
would probably involve

1. Adding a maxRows parameter to MappingSQLQueryWithParameters 
(defaulting to infinite).

2. Adding a TooManyRowsException (or something).

3. Checking the rowcount here

http://monkeymachine.co.uk/spring/xref/org/springframework/jdbc/object/MappingSqlQueryWithParameters.html#112

and throwing the exception if it's exceeded. I could write my own 
subclass and ResultReader but just wanted to see if people thought it 
would be sufficiently generic to be worthwhile including in the 
framework classes.

Luke.

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

Re: [Springframework-developer] Rationale for setApplicationContext() coming after afterPropertiesSet()

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

Good point. I'll rework it into two methods: =
postProcessBeforeInitialization and postProcessAfterInitialization.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Sa 10.01.2004 20:26
An: spr...@li...
Betreff: Re: [Springframework-developer] Rationale for =
setApplicationContext() coming after afterPropertiesSet()



Thanks Juergen.  My only comment about this particular implementation is
that if you are going to break backwards compatibility anyways by adding
a method to the interface, it would be more flexible to just add an
additional method for the pre-init stage, which would allow the same
post-processor to potentially handle post-processing for both stages.
Additionally, any hypothetical future stages would just add another
method...

Regards,
Colin


j=FCrgen h=F6ller [werk3AT] wrote:

>Colin, all,
>
>I've just implemented support for before- and after-initialization =
post-processors: The BeanPostProcessor interface has a new "boolean =
applyBeforeInitialization" method now, returning true for example in =
ApplicationContextAwareProcessor but false in AbstractAutoProxyCreator. =
BeanNameAware and BeanFactoryAware are also satisfied *before* =
initialization of the bean.
>
>In total, this gives the following initialization order for a bean now:
>1. setBeanName
>2. setBeanFactory
>3. setApplicationContext (only in a context, obviously)
>4. custom before-initialization BeanPostProcessors
>5. afterPropertiesSet / init-method
>6. custom after-initialization BeanPostProcessors
>
>I'll adapt the Javadocs accordingly.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von Colin Sampaleanu
>Gesendet: Mi 07.01.2004 14:09
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Rationale for =
setApplicationContext() coming after afterPropertiesSet()
>
>
>
>I was originally thinking of two marker interfaces for the initializing
>and post initializing BeanPostProcessors (as per a traditional listener
>design), but having two methods would also work fine...
>
>W/regards to the initializing one being allowed to return a wrapped
>instance of the bean, I am not sure there is anything really wrong with
>that. The distinction after all betwen the post processor types is for
>the most part on wether they come before or after the 'officially
>initialized' demarcation point (InitializingBean), and as such whether
>or not the post processor can expect a fully initialized bean, and
>whether the bean can expect at the dermarcation point that it is fully
>initialized. The fact that a post processor can wrap the bean before or
>after doesn't really change much...
>
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
>=20
>
>>Colin,
>>
>>You've got a point here. The current invocation order is a result of =
context implementation issues rather than design from the user =
perspective. I guess we won't have to worry about backward compatibility =
too much: After all, we discourage everyone to implement =
BeanFactoryAware of ApplicationContextAware for typical beans. With the =
new core.io.Resource stuff in M4, there's even one less reason to =
implement the latter.
>>
>>So let's design this in a clean and obvious manner for RC1. Your first =
suggestion sounds good to me: However, we would need to introduce a =
distinction between "initializing" BeanPostProcessors and =
"post-initializing" ones. This could happen via a marker sub-interface, =
for example, or via a new method in the interface.
>>
>>A special issue is that a BeanPostProcessor can return a wrapped =
instance of the bean: This isn't really desirable for "initializing" =
BeanPostProcessors, is it? So maybe we'd even need to introduce a =
separate interface that just allows processing of the given bean =
instance. Any thoughts?
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag =
von Colin Sampaleanu
>>Gesendet: Mi 07.01.2004 05:54
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] Rationale for =
setApplicationContext() coming after afterPropertiesSet()
>>
>>
>>
>>I was hoping for some more discussion on this, but it looks like =
nobody
>>bit...
>>
>>In the meantime, I have clarified the existing ordering of the =
lifecycle
>>methods in the JavaDocs for InitializingBean, BeanFactoryAware, and
>>ApplcationContextAware.
>>
>>I still think there somewhat of a (big) hole with regards to the =
current
>>initializing method handling. Currently, BeanPostProcessors are all
>>applied _after_ ApplicationContextAware (although this order is not
>>documented). This works for any BeanPostProcessors which expect to be
>>given fully initialized beans, as they will be given a bean =
initialized
>>fully (and knowing it) due to use of afterPropertiesSet
>>(InitializingBean), setBeanFactory (BeanFactoryAware), or
>>setApplicationContext (ApplicationContextAware). However, if somebody
>>needs to apply a BeanPostProcessor to set some properties of a bean as
>>part of the initialization, there is _no_ reliable mechanism to call =
an
>>init method on the bean afterwards; neither via an entry in the XML =
def,
>>nor via a marker interface.
>>
>>What makes the most sense to _me_ is to have the following sequence =
apply:
>>-  BeanFactoryAware, ApplicationContextAware, a set of 'initializing'
>>BeanPostProcessors, InitializingBean, and finally a another set of
>>'post-initializing' BeanPostProcessors.
>>
>>This obviously has implications in terms of backwards compatibility
>>since InitializingBean applies in a different sequence. A solution =
which
>>would be completely backwards compatible (but I think less obvious),
>>would be to do
>>- InitializingBean, BeanFactoryAware, 'initializing' =
BeanPostProcessors,
>>ApplicationContextAware, 'post-initializing' BeanPostProcessors. =
People
>>could in this case use any of the three marker interfaces to =
initialize,
>>as suitable...
>>
>>Any comments?
>>
>>Regards,
>>Colin
>>
>>Colin Sampaleanu wrote:
>>
>>
>>
>>  =20
>>
>>>I think any distinction between 'basic JavaBean stuff' and
>>>'application context stuff' is often going to be artificial. If you
>>>think about some class that actually needs the context, it is =
probably
>>>going to use it in a similar fashion to any other property inside it.
>>>
>>>But the initialize method (or the specific instance
>>>afterPropertiesSet) is also a lifecycle method, and it is in the =
wrong
>>>order as far as _any_ BeanPostProcessors are concerned, including
>>>ApplicationContextAware. Right now there is no mechanism to specify
>>>that an init method should be called after everything has been done =
to
>>>it by the context, including post processors. You can't even rely on
>>>setApplicationContext() as your init method because in fact some
>>>post-processors may act after it.
>>>
>>>If you think about it, you should be able to take a working
>>>beanfactory, with working beans, and if you need something special
>>>    =20
>>>
>>>from the application context (like the post-processors, or =
indirectly,
>>  =20
>>
>>>via the fact that one of its dependencies needs the application
>>>context) just switch to using the same setup in an application
>>>context. You can't really do that if you can no longer rely on the
>>>original init methods from when you were in the bean factory.
>>>
>>>So for sure I think there is a need for the ability to call an init
>>>method once post-processing is done, and I can't see the =
justification
>>>for making this different than the existing beanfactory init =
mechanism...
>>>
>>>Regards,
>>>Colin
>>>
>>>Rod Johnson wrote:
>>>
>>>=20
>>>
>>>    =20
>>>
>>>>Colin,
>>>>
>>>>I like the present order: not surprisingly, perhaps, as I chose it. =
The
>>>>rationale is: get the basic JavaBean stuff in order first, then do =
any
>>>>application context stuff.
>>>>
>>>>Certainly the docs should be consistent.
>>>>
>>>>Now at least I understand the confusion: setApplicationContext() is =
not
>>>>treated as a normal JavaBean property, but as a lifecycle method.
>>>>Perhaps
>>>>the "set" prefix was unwise.
>>>>
>>>>Regards,
>>>>Rod
>>>>
>>>>----- Original Message ----- From: "Colin Sampaleanu"
>>>><col...@ex...>
>>>>To: <spr...@li...>
>>>>Sent: Monday, January 05, 2004 8:35 PM
>>>>Subject: [Springframework-developer] Rationale for
>>>>setApplicationContext()
>>>>coming after afterPropertiesSet()
>>>>
>>>>
>>>>I've had a couple of discussions now with people where I've tried to
>>>>explain why setApplicationContext comes after afterPropertiesSet =
(and
>>>>after any custom initializing method you define), and frankly, I =
think
>>>>it just doesn't make sense except for the fact that it's that way
>>>>right now.
>>>>
>>>>Most beans should of course not be using the application context, =
but if
>>>>they need it, people are not going to understand the rationale as to =
why
>>>>that property is set after the initializing method is called, and =
that
>>>>they must instead treat setApplicationContext itself as an =
initializer
>>>>method.
>>>>
>>>>I don't know if anybody thinks it's worth changing the order, but if
>>>>not, this thing is going to hit new users on the head on a regular
>>>>basis... At a minimum, if no code is changed, we need to update the
>>>>JavaDoc for ApplicationContextAware to explain the order. I can do
>>>>that...
>>>>
>>>>Regards,
>>>>Colin
>>>>
>>>>j=FCrgen h=F6ller [werk3AT] wrote:
>>>>
>>>>
>>>>
>>>>  =20
>>>>
>>>>      =20
>>>>
>>>>>Actually, this is intended behavior, although it may be debatable
>>>>>whether
>>>>>
>>>>>    =20
>>>>>
>>>>>        =20
>>>>>
>>>>it is appropriate. setApplicationContext is not really meant to be
>>>>combined
>>>>with an init-method. The latter is for non-Spring-aware beans, while =
the
>>>>former is the strongest dependency a bean can have on Spring. You =
should
>>>>*not* design your beans to depend on that initialization order.
>>>>
>>>>
>>>>  =20
>>>>
>>>>      =20
>>>>
>>>>>As a solution, you could put your initialization code in your
>>>>>
>>>>>    =20
>>>>>
>>>>>        =20
>>>>>
>>>>setApplicationContext implementation, or in an =
initApplicationContext()
>>>>method that gets triggered by setApplicationContext. Have a look at =
the
>>>>ApplicationObjectSupport convenience base class, it provides such a
>>>>method
>>>>out of the box. Of course, extending ApplicationObjectSupport is not =
an
>>>>option if you already have a different natural base class.
>>>>
>>>>
>>>>  =20
>>>>
>>>>      =20
>>>>
>>>>>Juergen
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: Keith Donald [mailto:kd...@cs...]
>>>>>Sent: Thursday, October 30, 2003 4:22 PM
>>>>>To: spr...@li...
>>>>>Subject: RE: [Springframework-user] setApplicationContext not being
>>>>>called
>>>>>
>>>>>
>>>>>Juergen,
>>>>>
>>>>>Wanted to update you on this issue post M2.  setApplicationContext
>>>>>is being
>>>>>
>>>>>    =20
>>>>>
>>>>>        =20
>>>>>
>>>>called now on all my ApplicationContextAware beans, thanks.  The =
only
>>>>issue
>>>>I have remaining is it seems the bean init-method method
>>>>("initialize()" in
>>>>my case) is called by the container before setApplicationContext.  =
My
>>>>initialize() method does stuff that requires the context - for
>>>>example, it
>>>>looks up messages for initializing view components.  So I would
>>>>really need
>>>>setApplicationContext() called before initialize() to prevent
>>>>NullPointerExceptions.
>>>>
>>>>
>>>>  =20
>>>>
>>>>      =20
>>>>
>>>>>Thanks,
>>>>>Keith
>>>>>
>>>>>2003-10-30 10:16:58,099 DEBUG =
[com.csi.cogids.console.QueryNavigator] -
>>>>>
>>>>>    =20
>>>>>
>>>>>        =20
>>>>>
>>>><initialize called>
>>>>
>>>>
>>>>  =20
>>>>
>>>>      =20
>>>>
>>>>>2003-10-30 10:16:58,193 DEBUG
>>>>>[com.csi.cogids.console.qQueryNavigator] -
>>>>>
>>>>>    =20
>>>>>
>>>>>        =20
>>>>>
>>>><setApplicationContext called>
>>>>
>>>>
>>>>  =20
>>>>
>>>>      =20
>>>>
>>>>>Keith Donald
>>>>>Senior Software Engineer
>>>>>kd...@cs...
>>>>>321-676-2923 x403
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: spr...@li...
>>>>>
>>>>>    =20
>>>>>
>>>>>        =20
>>>>>
>>>>[mailto:spr...@li...] On Behalf =
Of
>>>>j=FCrgen h=F6ller [werk3AT]
>>>>
>>>>
>>>>  =20
>>>>
>>>>      =20
>>>>
>>>>>Sent: Thursday, October 23, 2003 2:14 AM
>>>>>To: spr...@li...
>>>>>Subject: Re: [Springframework-user] setApplicationContext not being
>>>>>called
>>>>>
>>>>>
>>>>>Keith,
>>>>>
>>>>>This was caused by the fact that ApplicationContextAware was being
>>>>>
>>>>>    =20
>>>>>
>>>>>        =20
>>>>>
>>>>processed after the underlying bean factory finished its work, on
>>>>demand in
>>>>getBean calls to the application context. I've completely reworked
>>>>this for
>>>>1.0 M2; now, the bean factory has a BeanPostProcessor hook that is =
also
>>>>internally used for processing ApplicationContextAware beans, to be
>>>>applied
>>>>when the underlying bean factory creates any kind of bean.
>>>>
>>>>
>>>>  =20
>>>>
>>>>      =20
>>>>
>>>>>So as of 1.0 M2, to be released tomorrow, this should work properly
>>>>>in all
>>>>>
>>>>>    =20
>>>>>
>>>>>        =20
>>>>>
>>>>cases. If there should be any remaining issues, please report them
>>>>against
>>>>1.0 M2. If you're eager, you can also try a CVS snapshot today.
>>>>
>>>>
>>>>  =20
>>>>
>>>>      =20
>>>>
>>>>>Juergen
>>>>>
>>>>>
>>>>>
>>>>>-----Urspr=FCngliche Nachricht----- Von: Keith Donald
>>>>>[mailto:kd...@cs...]
>>>>>Gesendet: Di 21.10.2003 19:50
>>>>>An: spr...@li...
>>>>>Cc:
>>>>>Betreff: [Springframework-user] setApplicationContext not being =
called
>>>>>
>>>>>
>>>>>
>>>>>Forgive me if this issue has already been addressd.  It appears
>>>>>setApplicationContext(ApplicationContext) is not being called on my
>>>>>ApplicationContextAware prototype beans that are not directly
>>>>>instantiated
>>>>>by a call to beanFactory.getBean(beanName), but rather are wired
>>>>>"child"
>>>>>beans instantiated as a result of a <bean ref> references from a =
parent
>>>>>prototype.
>>>>>
>>>>>To give you an example of what I mean:
>>>>>
>>>>>      // parent prototype
>>>>>      <bean      id=3D"sessionVisualizerPage"
>>>>>              =
class=3D"com.csi.cogids.console.SessionVisualizerPage"
>>>>>          singleton=3D"false">
>>>>>        <property name=3D"queryNavigator"><ref
>>>>>bean=3D"queryNavigator"/></property>
>>>>>   </bean>
>>>>>
>>>>>      // child prototype
>>>>>  <bean       id=3D"queryNavigator"
>>>>>           class=3D"com.csi.cogids.console.query.QueryNavigator"
>>>>>       singleton=3D"false"
>>>>>     init-method=3D"initialize">
>>>>>    <property name=3D"newQueryAction"><ref
>>>>>bean=3D"newQueryAction"/></property>
>>>>>    <property name=3D"newGroupAction"><ref
>>>>>bean=3D"newGroupAction"/></property>
>>>>>  </bean>
>>>>>
>>>>>A sessionVisualizerPage prototype gets instantiated when the page =
is
>>>>>
>>>>>    =20
>>>>>
>>>>>        =20
>>>>>
>>>>loaded
>>>>
>>>>
>>>>  =20
>>>>
>>>>      =20
>>>>
>>>>>in my application.  The queryNavigator prototype also gets =
instantiated
>>>>>because of the <bean ref>.  setApplicationContext() IS called on
>>>>>sessionVisualizerPage, but not on QueryNavigator, even though both =
are
>>>>>ApplicationContextAware for message lookups.
>>>>>
>>>>>Thanks,
>>>>>Keith
>>>>>
>>>>>Keith Donald
>>>>>Senior Software Engineer
>>>>>kd...@cs...
>>>>>321-676-2923 x403
>>>>>
>>>>>    =20
>>>>>
>>>>>        =20
>>>>>





-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Rationale for setApplicationContext() coming after afterPropertiesSet()

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

Thanks Juergen.  My only comment about this particular implementation is 
that if you are going to break backwards compatibility anyways by adding 
a method to the interface, it would be more flexible to just add an 
additional method for the pre-init stage, which would allow the same 
post-processor to potentially handle post-processing for both stages. 
Additionally, any hypothetical future stages would just add another 
method...

Regards,
Colin


jürgen höller [werk3AT] wrote:

>Colin, all,
> 
>I've just implemented support for before- and after-initialization post-processors: The BeanPostProcessor interface has a new "boolean applyBeforeInitialization" method now, returning true for example in ApplicationContextAwareProcessor but false in AbstractAutoProxyCreator. BeanNameAware and BeanFactoryAware are also satisfied *before* initialization of the bean.
> 
>In total, this gives the following initialization order for a bean now:
>1. setBeanName
>2. setBeanFactory
>3. setApplicationContext (only in a context, obviously)
>4. custom before-initialization BeanPostProcessors
>5. afterPropertiesSet / init-method
>6. custom after-initialization BeanPostProcessors
> 
>I'll adapt the Javadocs accordingly.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: Mi 07.01.2004 14:09
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Rationale for setApplicationContext() coming after afterPropertiesSet()
>
>
>
>I was originally thinking of two marker interfaces for the initializing
>and post initializing BeanPostProcessors (as per a traditional listener
>design), but having two methods would also work fine...
>
>W/regards to the initializing one being allowed to return a wrapped
>instance of the bean, I am not sure there is anything really wrong with
>that. The distinction after all betwen the post processor types is for
>the most part on wether they come before or after the 'officially
>initialized' demarcation point (InitializingBean), and as such whether
>or not the post processor can expect a fully initialized bean, and
>whether the bean can expect at the dermarcation point that it is fully
>initialized. The fact that a post processor can wrap the bean before or
>after doesn't really change much...
>
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Colin,
>>
>>You've got a point here. The current invocation order is a result of context implementation issues rather than design from the user perspective. I guess we won't have to worry about backward compatibility too much: After all, we discourage everyone to implement BeanFactoryAware of ApplicationContextAware for typical beans. With the new core.io.Resource stuff in M4, there's even one less reason to implement the latter.
>>
>>So let's design this in a clean and obvious manner for RC1. Your first suggestion sounds good to me: However, we would need to introduce a distinction between "initializing" BeanPostProcessors and "post-initializing" ones. This could happen via a marker sub-interface, for example, or via a new method in the interface.
>>
>>A special issue is that a BeanPostProcessor can return a wrapped instance of the bean: This isn't really desirable for "initializing" BeanPostProcessors, is it? So maybe we'd even need to introduce a separate interface that just allows processing of the given bean instance. Any thoughts?
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von Colin Sampaleanu
>>Gesendet: Mi 07.01.2004 05:54
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] Rationale for setApplicationContext() coming after afterPropertiesSet()
>>
>>
>>
>>I was hoping for some more discussion on this, but it looks like nobody
>>bit...
>>
>>In the meantime, I have clarified the existing ordering of the lifecycle
>>methods in the JavaDocs for InitializingBean, BeanFactoryAware, and
>>ApplcationContextAware.
>>
>>I still think there somewhat of a (big) hole with regards to the current
>>initializing method handling. Currently, BeanPostProcessors are all
>>applied _after_ ApplicationContextAware (although this order is not
>>documented). This works for any BeanPostProcessors which expect to be
>>given fully initialized beans, as they will be given a bean initialized
>>fully (and knowing it) due to use of afterPropertiesSet
>>(InitializingBean), setBeanFactory (BeanFactoryAware), or
>>setApplicationContext (ApplicationContextAware). However, if somebody
>>needs to apply a BeanPostProcessor to set some properties of a bean as
>>part of the initialization, there is _no_ reliable mechanism to call an
>>init method on the bean afterwards; neither via an entry in the XML def,
>>nor via a marker interface.
>>
>>What makes the most sense to _me_ is to have the following sequence apply:
>>-  BeanFactoryAware, ApplicationContextAware, a set of 'initializing'
>>BeanPostProcessors, InitializingBean, and finally a another set of
>>'post-initializing' BeanPostProcessors.
>>
>>This obviously has implications in terms of backwards compatibility
>>since InitializingBean applies in a different sequence. A solution which
>>would be completely backwards compatible (but I think less obvious),
>>would be to do
>>- InitializingBean, BeanFactoryAware, 'initializing' BeanPostProcessors,
>>ApplicationContextAware, 'post-initializing' BeanPostProcessors. People
>>could in this case use any of the three marker interfaces to initialize,
>>as suitable...
>>
>>Any comments?
>>
>>Regards,
>>Colin
>>
>>Colin Sampaleanu wrote:
>>
>>
>>
>>    
>>
>>>I think any distinction between 'basic JavaBean stuff' and
>>>'application context stuff' is often going to be artificial. If you
>>>think about some class that actually needs the context, it is probably
>>>going to use it in a similar fashion to any other property inside it.
>>>
>>>But the initialize method (or the specific instance
>>>afterPropertiesSet) is also a lifecycle method, and it is in the wrong
>>>order as far as _any_ BeanPostProcessors are concerned, including
>>>ApplicationContextAware. Right now there is no mechanism to specify
>>>that an init method should be called after everything has been done to
>>>it by the context, including post processors. You can't even rely on
>>>setApplicationContext() as your init method because in fact some
>>>post-processors may act after it.
>>>
>>>If you think about it, you should be able to take a working
>>>beanfactory, with working beans, and if you need something special
>>>      
>>>
>>>from the application context (like the post-processors, or indirectly,
>>    
>>
>>>via the fact that one of its dependencies needs the application
>>>context) just switch to using the same setup in an application
>>>context. You can't really do that if you can no longer rely on the
>>>original init methods from when you were in the bean factory.
>>>
>>>So for sure I think there is a need for the ability to call an init
>>>method once post-processing is done, and I can't see the justification
>>>for making this different than the existing beanfactory init mechanism...
>>>
>>>Regards,
>>>Colin
>>>
>>>Rod Johnson wrote:
>>>
>>>  
>>>
>>>      
>>>
>>>>Colin,
>>>>
>>>>I like the present order: not surprisingly, perhaps, as I chose it. The
>>>>rationale is: get the basic JavaBean stuff in order first, then do any
>>>>application context stuff.
>>>>
>>>>Certainly the docs should be consistent.
>>>>
>>>>Now at least I understand the confusion: setApplicationContext() is not
>>>>treated as a normal JavaBean property, but as a lifecycle method.
>>>>Perhaps
>>>>the "set" prefix was unwise.
>>>>
>>>>Regards,
>>>>Rod
>>>>
>>>>----- Original Message ----- From: "Colin Sampaleanu"
>>>><col...@ex...>
>>>>To: <spr...@li...>
>>>>Sent: Monday, January 05, 2004 8:35 PM
>>>>Subject: [Springframework-developer] Rationale for
>>>>setApplicationContext()
>>>>coming after afterPropertiesSet()
>>>>
>>>>
>>>>I've had a couple of discussions now with people where I've tried to
>>>>explain why setApplicationContext comes after afterPropertiesSet (and
>>>>after any custom initializing method you define), and frankly, I think
>>>>it just doesn't make sense except for the fact that it's that way
>>>>right now.
>>>>
>>>>Most beans should of course not be using the application context, but if
>>>>they need it, people are not going to understand the rationale as to why
>>>>that property is set after the initializing method is called, and that
>>>>they must instead treat setApplicationContext itself as an initializer
>>>>method.
>>>>
>>>>I don't know if anybody thinks it's worth changing the order, but if
>>>>not, this thing is going to hit new users on the head on a regular
>>>>basis... At a minimum, if no code is changed, we need to update the
>>>>JavaDoc for ApplicationContextAware to explain the order. I can do
>>>>that...
>>>>
>>>>Regards,
>>>>Colin
>>>>
>>>>jürgen höller [werk3AT] wrote:
>>>>
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>>>Actually, this is intended behavior, although it may be debatable
>>>>>whether
>>>>>
>>>>>      
>>>>>
>>>>>          
>>>>>
>>>>it is appropriate. setApplicationContext is not really meant to be
>>>>combined
>>>>with an init-method. The latter is for non-Spring-aware beans, while the
>>>>former is the strongest dependency a bean can have on Spring. You should
>>>>*not* design your beans to depend on that initialization order.
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>>>As a solution, you could put your initialization code in your
>>>>>
>>>>>      
>>>>>
>>>>>          
>>>>>
>>>>setApplicationContext implementation, or in an initApplicationContext()
>>>>method that gets triggered by setApplicationContext. Have a look at the
>>>>ApplicationObjectSupport convenience base class, it provides such a
>>>>method
>>>>out of the box. Of course, extending ApplicationObjectSupport is not an
>>>>option if you already have a different natural base class.
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>>>Juergen
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: Keith Donald [mailto:kd...@cs...]
>>>>>Sent: Thursday, October 30, 2003 4:22 PM
>>>>>To: spr...@li...
>>>>>Subject: RE: [Springframework-user] setApplicationContext not being
>>>>>called
>>>>>
>>>>>
>>>>>Juergen,
>>>>>
>>>>>Wanted to update you on this issue post M2.  setApplicationContext
>>>>>is being
>>>>>
>>>>>      
>>>>>
>>>>>          
>>>>>
>>>>called now on all my ApplicationContextAware beans, thanks.  The only
>>>>issue
>>>>I have remaining is it seems the bean init-method method
>>>>("initialize()" in
>>>>my case) is called by the container before setApplicationContext.  My
>>>>initialize() method does stuff that requires the context - for
>>>>example, it
>>>>looks up messages for initializing view components.  So I would
>>>>really need
>>>>setApplicationContext() called before initialize() to prevent
>>>>NullPointerExceptions.
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>>>Thanks,
>>>>>Keith
>>>>>
>>>>>2003-10-30 10:16:58,099 DEBUG [com.csi.cogids.console.QueryNavigator] -
>>>>>
>>>>>      
>>>>>
>>>>>          
>>>>>
>>>><initialize called>
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>>>2003-10-30 10:16:58,193 DEBUG
>>>>>[com.csi.cogids.console.qQueryNavigator] -
>>>>>
>>>>>      
>>>>>
>>>>>          
>>>>>
>>>><setApplicationContext called>
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>>>Keith Donald
>>>>>Senior Software Engineer
>>>>>kd...@cs...
>>>>>321-676-2923 x403
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: spr...@li...
>>>>>
>>>>>      
>>>>>
>>>>>          
>>>>>
>>>>[mailto:spr...@li...] On Behalf Of
>>>>jürgen höller [werk3AT]
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>>>Sent: Thursday, October 23, 2003 2:14 AM
>>>>>To: spr...@li...
>>>>>Subject: Re: [Springframework-user] setApplicationContext not being
>>>>>called
>>>>>
>>>>>
>>>>>Keith,
>>>>>
>>>>>This was caused by the fact that ApplicationContextAware was being
>>>>>
>>>>>      
>>>>>
>>>>>          
>>>>>
>>>>processed after the underlying bean factory finished its work, on
>>>>demand in
>>>>getBean calls to the application context. I've completely reworked
>>>>this for
>>>>1.0 M2; now, the bean factory has a BeanPostProcessor hook that is also
>>>>internally used for processing ApplicationContextAware beans, to be
>>>>applied
>>>>when the underlying bean factory creates any kind of bean.
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>>>So as of 1.0 M2, to be released tomorrow, this should work properly
>>>>>in all
>>>>>
>>>>>      
>>>>>
>>>>>          
>>>>>
>>>>cases. If there should be any remaining issues, please report them
>>>>against
>>>>1.0 M2. If you're eager, you can also try a CVS snapshot today.
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>>>Juergen
>>>>>
>>>>>
>>>>>
>>>>>-----Ursprüngliche Nachricht----- Von: Keith Donald
>>>>>[mailto:kd...@cs...]
>>>>>Gesendet: Di 21.10.2003 19:50
>>>>>An: spr...@li...
>>>>>Cc:
>>>>>Betreff: [Springframework-user] setApplicationContext not being called
>>>>>
>>>>>
>>>>>
>>>>>Forgive me if this issue has already been addressd.  It appears
>>>>>setApplicationContext(ApplicationContext) is not being called on my
>>>>>ApplicationContextAware prototype beans that are not directly
>>>>>instantiated
>>>>>by a call to beanFactory.getBean(beanName), but rather are wired
>>>>>"child"
>>>>>beans instantiated as a result of a <bean ref> references from a parent
>>>>>prototype.
>>>>>
>>>>>To give you an example of what I mean:
>>>>>
>>>>>      // parent prototype
>>>>>      <bean      id="sessionVisualizerPage"
>>>>>              class="com.csi.cogids.console.SessionVisualizerPage"
>>>>>          singleton="false">
>>>>>        <property name="queryNavigator"><ref
>>>>>bean="queryNavigator"/></property>
>>>>>   </bean>
>>>>>
>>>>>      // child prototype
>>>>>  <bean       id="queryNavigator"
>>>>>           class="com.csi.cogids.console.query.QueryNavigator"
>>>>>       singleton="false"
>>>>>     init-method="initialize">
>>>>>    <property name="newQueryAction"><ref
>>>>>bean="newQueryAction"/></property>
>>>>>    <property name="newGroupAction"><ref
>>>>>bean="newGroupAction"/></property>
>>>>>  </bean>
>>>>>
>>>>>A sessionVisualizerPage prototype gets instantiated when the page is
>>>>>
>>>>>      
>>>>>
>>>>>          
>>>>>
>>>>loaded
>>>>
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>>>in my application.  The queryNavigator prototype also gets instantiated
>>>>>because of the <bean ref>.  setApplicationContext() IS called on
>>>>>sessionVisualizerPage, but not on QueryNavigator, even though both are
>>>>>ApplicationContextAware for message lookups.
>>>>>
>>>>>Thanks,
>>>>>Keith
>>>>>
>>>>>Keith Donald
>>>>>Senior Software Engineer
>>>>>kd...@cs...
>>>>>321-676-2923 x403
>>>>>
>>>>>      
>>>>>
>>>>>          
>>>>>

Re: [Springframework-developer] Rationale for setApplicationContext() coming after afterPropertiesSet()

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

Colin, all,
=20
I've just implemented support for before- and after-initialization =
post-processors: The BeanPostProcessor interface has a new "boolean =
applyBeforeInitialization" method now, returning true for example in =
ApplicationContextAwareProcessor but false in AbstractAutoProxyCreator. =
BeanNameAware and BeanFactoryAware are also satisfied *before* =
initialization of the bean.
=20
In total, this gives the following initialization order for a bean now:
1. setBeanName
2. setBeanFactory
3. setApplicationContext (only in a context, obviously)
4. custom before-initialization BeanPostProcessors
5. afterPropertiesSet / init-method
6. custom after-initialization BeanPostProcessors
=20
I'll adapt the Javadocs accordingly.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Mi 07.01.2004 14:09
An: spr...@li...
Betreff: Re: [Springframework-developer] Rationale for =
setApplicationContext() coming after afterPropertiesSet()



I was originally thinking of two marker interfaces for the initializing
and post initializing BeanPostProcessors (as per a traditional listener
design), but having two methods would also work fine...

W/regards to the initializing one being allowed to return a wrapped
instance of the bean, I am not sure there is anything really wrong with
that. The distinction after all betwen the post processor types is for
the most part on wether they come before or after the 'officially
initialized' demarcation point (InitializingBean), and as such whether
or not the post processor can expect a fully initialized bean, and
whether the bean can expect at the dermarcation point that it is fully
initialized. The fact that a post processor can wrap the bean before or
after doesn't really change much...


j=FCrgen h=F6ller [werk3AT] wrote:

>Colin,
>
>You've got a point here. The current invocation order is a result of =
context implementation issues rather than design from the user =
perspective. I guess we won't have to worry about backward compatibility =
too much: After all, we discourage everyone to implement =
BeanFactoryAware of ApplicationContextAware for typical beans. With the =
new core.io.Resource stuff in M4, there's even one less reason to =
implement the latter.
>
>So let's design this in a clean and obvious manner for RC1. Your first =
suggestion sounds good to me: However, we would need to introduce a =
distinction between "initializing" BeanPostProcessors and =
"post-initializing" ones. This could happen via a marker sub-interface, =
for example, or via a new method in the interface.
>
>A special issue is that a BeanPostProcessor can return a wrapped =
instance of the bean: This isn't really desirable for "initializing" =
BeanPostProcessors, is it? So maybe we'd even need to introduce a =
separate interface that just allows processing of the given bean =
instance. Any thoughts?
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von Colin Sampaleanu
>Gesendet: Mi 07.01.2004 05:54
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Rationale for =
setApplicationContext() coming after afterPropertiesSet()
>
>
>
>I was hoping for some more discussion on this, but it looks like nobody
>bit...
>
>In the meantime, I have clarified the existing ordering of the =
lifecycle
>methods in the JavaDocs for InitializingBean, BeanFactoryAware, and
>ApplcationContextAware.
>
>I still think there somewhat of a (big) hole with regards to the =
current
>initializing method handling. Currently, BeanPostProcessors are all
>applied _after_ ApplicationContextAware (although this order is not
>documented). This works for any BeanPostProcessors which expect to be
>given fully initialized beans, as they will be given a bean initialized
>fully (and knowing it) due to use of afterPropertiesSet
>(InitializingBean), setBeanFactory (BeanFactoryAware), or
>setApplicationContext (ApplicationContextAware). However, if somebody
>needs to apply a BeanPostProcessor to set some properties of a bean as
>part of the initialization, there is _no_ reliable mechanism to call an
>init method on the bean afterwards; neither via an entry in the XML =
def,
>nor via a marker interface.
>
>What makes the most sense to _me_ is to have the following sequence =
apply:
>-  BeanFactoryAware, ApplicationContextAware, a set of 'initializing'
>BeanPostProcessors, InitializingBean, and finally a another set of
>'post-initializing' BeanPostProcessors.
>
>This obviously has implications in terms of backwards compatibility
>since InitializingBean applies in a different sequence. A solution =
which
>would be completely backwards compatible (but I think less obvious),
>would be to do
>- InitializingBean, BeanFactoryAware, 'initializing' =
BeanPostProcessors,
>ApplicationContextAware, 'post-initializing' BeanPostProcessors. People
>could in this case use any of the three marker interfaces to =
initialize,
>as suitable...
>
>Any comments?
>
>Regards,
>Colin
>
>Colin Sampaleanu wrote:
>
>=20
>
>>I think any distinction between 'basic JavaBean stuff' and
>>'application context stuff' is often going to be artificial. If you
>>think about some class that actually needs the context, it is probably
>>going to use it in a similar fashion to any other property inside it.
>>
>>But the initialize method (or the specific instance
>>afterPropertiesSet) is also a lifecycle method, and it is in the wrong
>>order as far as _any_ BeanPostProcessors are concerned, including
>>ApplicationContextAware. Right now there is no mechanism to specify
>>that an init method should be called after everything has been done to
>>it by the context, including post processors. You can't even rely on
>>setApplicationContext() as your init method because in fact some
>>post-processors may act after it.
>>
>>If you think about it, you should be able to take a working
>>beanfactory, with working beans, and if you need something special
>>from the application context (like the post-processors, or indirectly,
>>via the fact that one of its dependencies needs the application
>>context) just switch to using the same setup in an application
>>context. You can't really do that if you can no longer rely on the
>>original init methods from when you were in the bean factory.
>>
>>So for sure I think there is a need for the ability to call an init
>>method once post-processing is done, and I can't see the justification
>>for making this different than the existing beanfactory init =
mechanism...
>>
>>Regards,
>>Colin
>>
>>Rod Johnson wrote:
>>
>>  =20
>>
>>>Colin,
>>>
>>>I like the present order: not surprisingly, perhaps, as I chose it. =
The
>>>rationale is: get the basic JavaBean stuff in order first, then do =
any
>>>application context stuff.
>>>
>>>Certainly the docs should be consistent.
>>>
>>>Now at least I understand the confusion: setApplicationContext() is =
not
>>>treated as a normal JavaBean property, but as a lifecycle method.
>>>Perhaps
>>>the "set" prefix was unwise.
>>>
>>>Regards,
>>>Rod
>>>
>>>----- Original Message ----- From: "Colin Sampaleanu"
>>><col...@ex...>
>>>To: <spr...@li...>
>>>Sent: Monday, January 05, 2004 8:35 PM
>>>Subject: [Springframework-developer] Rationale for
>>>setApplicationContext()
>>>coming after afterPropertiesSet()
>>>
>>>
>>>I've had a couple of discussions now with people where I've tried to
>>>explain why setApplicationContext comes after afterPropertiesSet (and
>>>after any custom initializing method you define), and frankly, I =
think
>>>it just doesn't make sense except for the fact that it's that way
>>>right now.
>>>
>>>Most beans should of course not be using the application context, but =
if
>>>they need it, people are not going to understand the rationale as to =
why
>>>that property is set after the initializing method is called, and =
that
>>>they must instead treat setApplicationContext itself as an =
initializer
>>>method.
>>>
>>>I don't know if anybody thinks it's worth changing the order, but if
>>>not, this thing is going to hit new users on the head on a regular
>>>basis... At a minimum, if no code is changed, we need to update the
>>>JavaDoc for ApplicationContextAware to explain the order. I can do
>>>that...
>>>
>>>Regards,
>>>Colin
>>>
>>>j=FCrgen h=F6ller [werk3AT] wrote:
>>>
>>>
>>>
>>>    =20
>>>
>>>>Actually, this is intended behavior, although it may be debatable
>>>>whether
>>>>
>>>>      =20
>>>>
>>>it is appropriate. setApplicationContext is not really meant to be
>>>combined
>>>with an init-method. The latter is for non-Spring-aware beans, while =
the
>>>former is the strongest dependency a bean can have on Spring. You =
should
>>>*not* design your beans to depend on that initialization order.
>>>
>>>
>>>    =20
>>>
>>>>As a solution, you could put your initialization code in your
>>>>
>>>>      =20
>>>>
>>>setApplicationContext implementation, or in an =
initApplicationContext()
>>>method that gets triggered by setApplicationContext. Have a look at =
the
>>>ApplicationObjectSupport convenience base class, it provides such a
>>>method
>>>out of the box. Of course, extending ApplicationObjectSupport is not =
an
>>>option if you already have a different natural base class.
>>>
>>>
>>>    =20
>>>
>>>>Juergen
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: Keith Donald [mailto:kd...@cs...]
>>>>Sent: Thursday, October 30, 2003 4:22 PM
>>>>To: spr...@li...
>>>>Subject: RE: [Springframework-user] setApplicationContext not being
>>>>called
>>>>
>>>>
>>>>Juergen,
>>>>
>>>>Wanted to update you on this issue post M2.  setApplicationContext
>>>>is being
>>>>
>>>>      =20
>>>>
>>>called now on all my ApplicationContextAware beans, thanks.  The only
>>>issue
>>>I have remaining is it seems the bean init-method method
>>>("initialize()" in
>>>my case) is called by the container before setApplicationContext.  My
>>>initialize() method does stuff that requires the context - for
>>>example, it
>>>looks up messages for initializing view components.  So I would
>>>really need
>>>setApplicationContext() called before initialize() to prevent
>>>NullPointerExceptions.
>>>
>>>
>>>    =20
>>>
>>>>Thanks,
>>>>Keith
>>>>
>>>>2003-10-30 10:16:58,099 DEBUG =
[com.csi.cogids.console.QueryNavigator] -
>>>>
>>>>      =20
>>>>
>>><initialize called>
>>>
>>>
>>>    =20
>>>
>>>>2003-10-30 10:16:58,193 DEBUG
>>>>[com.csi.cogids.console.qQueryNavigator] -
>>>>
>>>>      =20
>>>>
>>><setApplicationContext called>
>>>
>>>
>>>    =20
>>>
>>>>Keith Donald
>>>>Senior Software Engineer
>>>>kd...@cs...
>>>>321-676-2923 x403
>>>>
>>>>
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: spr...@li...
>>>>
>>>>      =20
>>>>
>>>[mailto:spr...@li...] On Behalf =
Of
>>>j=FCrgen h=F6ller [werk3AT]
>>>
>>>
>>>    =20
>>>
>>>>Sent: Thursday, October 23, 2003 2:14 AM
>>>>To: spr...@li...
>>>>Subject: Re: [Springframework-user] setApplicationContext not being
>>>>called
>>>>
>>>>
>>>>Keith,
>>>>
>>>>This was caused by the fact that ApplicationContextAware was being
>>>>
>>>>      =20
>>>>
>>>processed after the underlying bean factory finished its work, on
>>>demand in
>>>getBean calls to the application context. I've completely reworked
>>>this for
>>>1.0 M2; now, the bean factory has a BeanPostProcessor hook that is =
also
>>>internally used for processing ApplicationContextAware beans, to be
>>>applied
>>>when the underlying bean factory creates any kind of bean.
>>>
>>>
>>>    =20
>>>
>>>>So as of 1.0 M2, to be released tomorrow, this should work properly
>>>>in all
>>>>
>>>>      =20
>>>>
>>>cases. If there should be any remaining issues, please report them
>>>against
>>>1.0 M2. If you're eager, you can also try a CVS snapshot today.
>>>
>>>
>>>    =20
>>>
>>>>Juergen
>>>>
>>>>
>>>>
>>>>-----Urspr=FCngliche Nachricht----- Von: Keith Donald
>>>>[mailto:kd...@cs...]
>>>>Gesendet: Di 21.10.2003 19:50
>>>>An: spr...@li...
>>>>Cc:
>>>>Betreff: [Springframework-user] setApplicationContext not being =
called
>>>>
>>>>
>>>>
>>>>Forgive me if this issue has already been addressd.  It appears
>>>>setApplicationContext(ApplicationContext) is not being called on my
>>>>ApplicationContextAware prototype beans that are not directly
>>>>instantiated
>>>>by a call to beanFactory.getBean(beanName), but rather are wired
>>>>"child"
>>>>beans instantiated as a result of a <bean ref> references from a =
parent
>>>>prototype.
>>>>
>>>>To give you an example of what I mean:
>>>>
>>>>       // parent prototype
>>>>       <bean      id=3D"sessionVisualizerPage"
>>>>               =
class=3D"com.csi.cogids.console.SessionVisualizerPage"
>>>>           singleton=3D"false">
>>>>         <property name=3D"queryNavigator"><ref
>>>>bean=3D"queryNavigator"/></property>
>>>>    </bean>
>>>>
>>>>       // child prototype
>>>>   <bean       id=3D"queryNavigator"
>>>>            class=3D"com.csi.cogids.console.query.QueryNavigator"
>>>>        singleton=3D"false"
>>>>      init-method=3D"initialize">
>>>>     <property name=3D"newQueryAction"><ref
>>>>bean=3D"newQueryAction"/></property>
>>>>     <property name=3D"newGroupAction"><ref
>>>>bean=3D"newGroupAction"/></property>
>>>>   </bean>
>>>>
>>>>A sessionVisualizerPage prototype gets instantiated when the page is
>>>>
>>>>      =20
>>>>
>>>loaded
>>>
>>>
>>>    =20
>>>
>>>>in my application.  The queryNavigator prototype also gets =
instantiated
>>>>because of the <bean ref>.  setApplicationContext() IS called on
>>>>sessionVisualizerPage, but not on QueryNavigator, even though both =
are
>>>>ApplicationContextAware for message lookups.
>>>>
>>>>Thanks,
>>>>Keith
>>>>
>>>>Keith Donald
>>>>Senior Software Engineer
>>>>kd...@cs...
>>>>321-676-2923 x403
>>>>=20
>>>>      =20
>>>>





-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Web app deployment error after upgrading from m3 to m4

[Alastair R. <ala...@ph...>]

WW91J3JlIGFic29sdXRlbHkgcmlnaHQgRG1pdHJpeSEgU29ycnkgZm9yIHBvc3RpbmcgdGhpcyBw
cm9ibGVtIHByZW1hdHVyZWx5IC0gdGlyZWRuZXNzIGhhZCBjYXVzZWQgbWUgdG8gb25seSBjaGVj
ayB0aGUgSkJvc3MgbG9nLCBub3QgdGhlIFNwcmluZyBsb2chIFRoZSBsYXR0ZXIgaW5kaWNhdGVk
IHRoYXQgdGhlIHByb2JsZW0gd2FzIHRoYXQgSSBkaWRuJ3QgaGF2ZSBlaGNhY2hlLmphciBvbiB0
aGUgY2xhc3NwYXRoLCB3aGljaCBpcyByZXF1aXJlZCBieSBIaWJlcm5hdGUgMi4xLjEuIA0KDQpU
aGFua3MsDQpBbC4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNw
cmluZ2ZyYW1ld29yay1kZXZlbG9wZXItYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KPiBb
bWFpbHRvOnNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXItYWRtaW5AbGlzdHMuc291cmNlZm9yZ2Uu
bmV0XQ0KPiAgT24gQmVoYWxmIE9mIEtvcHlsZW5rbywgRG1pdHJ5DQo+IFNlbnQ6IDA5IEphbnVh
cnkgMjAwNCAxNTo0OA0KPiBUbzogJ3NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291
cmNlZm9yZ2UubmV0Jw0KPiBTdWJqZWN0OiBSRTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJd
IFdlYiBhcHAgZGVwbG95bWVudCANCj4gZXJyb3IgYWZ0ZXIgdXBncmFkaW5nIGZyb20gbTMgdG8g
bTQNCj4gDQo+IA0KPiBBbC4sDQo+IA0KPiB3aGF0IGlzIHRoZSByZXN0IG9mIHlvdXIgc3RhY2sg
dHJhY2U/IEl0J3MgcHJvYmFibHkgY2F1c2VkIGJ5IA0KPiBzb21lIGV4Y2VwdGlvbiBkdXJpbmcg
YmVhbiBpbml0aWFsaXphdGlvbiBpbiB5b3VyIGFwcGxpY2F0aW9uIGNvbnRleHQuDQo+IA0KPiBS
ZWdhcmRzLA0KPiBEbWl0cml5Lg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g
RnJvbTogQWxhc3RhaXIgUm9kZ2VycyBbbWFpbHRvOmFsYXN0YWlyLnJvZGdlcnNAcGhvY2lzLmNv
bV0gDQo+IFNlbnQ6IEZyaWRheSwgSmFudWFyeSAwOSwgMjAwNCAxMDo0MSBBTQ0KPiBUbzogc3By
aW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj4gU3ViamVjdDog
W1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIFdlYiBhcHAgZGVwbG95bWVudCBlcnJvciANCj4g
YWZ0ZXIgdXBncmFkaW5nIGZyb20gbTMgdG8gbTQNCj4gDQo+IA0KPiBIaSwgDQo+IA0KPiBJIGp1
c3QgdHJpZWQgdG8gdXBncmFkZSBmcm9tIG0zIHRvIG00IGJ1dCBnZXQgYW4gZXJyb3Igd2hlbiBJ
IA0KPiB0cnkgdG8gZGVwbG95IG15IHdlYiBhcHAuIFRoZSB3ZWIgYXBwIGhhcyBhIGNvbnRleHQg
bG9hZGVyIA0KPiBsaXN0ZW5lciBkZWZpbmVkIHdpdGg6IA0KPiANCj4gICA8Y29udGV4dC1wYXJh
bT4NCj4gICAgIDxwYXJhbS1uYW1lPmNvbnRleHRDb25maWdMb2NhdGlvbjwvcGFyYW0tbmFtZT4N
Cj4gIA0KPiA8cGFyYW0tdmFsdWU+L1dFQi1JTkYvYXBwbGljYXRpb25Db250ZXh0LWNvcmUueG1s
LC9XRUItSU5GL2FwcA0KPiBsaWNhdGlvbkNvbnRleA0KPiB0LXdlYi54bWw8L3BhcmFtLXZhbHVl
Pg0KPiAgIDwvY29udGV4dC1wYXJhbT4NCj4gDQo+ICAgPGxpc3RlbmVyPg0KPiAgDQo+IDxsaXN0
ZW5lci1jbGFzcz5vcmcuc3ByaW5nZnJhbWV3b3JrLndlYi5jb250ZXh0LkNvbnRleHRMb2FkZXJM
DQo+IGlzdGVuZXI8L2xpc3RlDQo+IG5lci1jbGFzcz4NCj4gICA8L2xpc3RlbmVyPg0KPiANCj4g
V2hlbiBJIHRyeSB0byBkZXBsb3kgaXQgSSBnZXQgYW4gZXhjZXB0aW9uIHNheWluZyAiTm8gDQo+
IFdlYkFwcGxpY2F0aW9uQ29udGV4dA0KPiBmb3VuZDogbm8gQ29udGV4dExvYWRlckxpc3RlbmVy
IHJlZ2lzdGVyZWQ/IiAoc3RhY2t0cmFjZSANCj4gYmVsb3cpLiBUaGlzIGFwcCB3b3JrZWQgZmlu
ZSB3aXRoIFNwcmluZyBtMywgYW5kIHRoZSBleGFtcGxlcyANCj4gcHJvdmlkZWQgd2l0aCBtNCBz
ZWVtIHRvIGluZGljYXRlIHRoaXMgc2hvdWxkIGJlIE9LLiBBbnkgaWRlYSANCj4gd2hhdCB0aGUg
cHJvYmxlbSBpcz8NCj4gDQo+IFJlZ2FyZHMsDQo+IEFsLg0KPiANCj4gDQo+IG9yZy5qYm9zcy5k
ZXBsb3ltZW50LkRlcGxveW1lbnRFeGNlcHRpb246IE5vIA0KPiBXZWJBcHBsaWNhdGlvbkNvbnRl
eHQgZm91bmQ6IG5vIENvbnRleHRMb2FkZXJMaXN0ZW5lciANCj4gcmVnaXN0ZXJlZD87IC0gbmVz
dGVkIHRocm93YWJsZToNCj4gKGphdmEubGFuZy5JbGxlZ2FsU3RhdGVFeGNlcHRpb246IE5vIFdl
YkFwcGxpY2F0aW9uQ29udGV4dCANCj4gZm91bmQ6IG5vIENvbnRleHRMb2FkZXJMaXN0ZW5lciBy
ZWdpc3RlcmVkPykNCj4gCWF0IG9yZy5qYm9zcy5qZXR0eS5KZXR0eS51bmRlcGxveShKZXR0eS5q
YXZhOjM4MSkNCj4gCWF0IG9yZy5qYm9zcy5qZXR0eS5KZXR0eS5kZXBsb3koSmV0dHkuamF2YToz
NTEpDQo+IAlhdCANCj4gb3JnLmpib3NzLmpldHR5LkpldHR5U2VydmljZS5wZXJmb3JtRGVwbG95
KEpldHR5U2VydmljZS5qYXZhOjI0MikNCj4gCWF0DQo+IG9yZy5qYm9zcy53ZWIuQWJzdHJhY3RX
ZWJDb250YWluZXIuc3RhcnQoQWJzdHJhY3RXZWJDb250YWluZXIuDQo+IGphdmE6NDI4KQ0KPiAJ
YXQgDQo+IG9yZy5qYm9zcy5kZXBsb3ltZW50Lk1haW5EZXBsb3llci5zdGFydChNYWluRGVwbG95
ZXIuamF2YTo4MzIpDQo+IAlhdCANCj4gb3JnLmpib3NzLmRlcGxveW1lbnQuTWFpbkRlcGxveWVy
LnN0YXJ0KE1haW5EZXBsb3llci5qYXZhOjgyNCkNCj4gCWF0IA0KPiBvcmcuamJvc3MuZGVwbG95
bWVudC5NYWluRGVwbG95ZXIuZGVwbG95KE1haW5EZXBsb3llci5qYXZhOjY0MikNCj4gCWF0IA0K
PiBvcmcuamJvc3MuZGVwbG95bWVudC5NYWluRGVwbG95ZXIuZGVwbG95KE1haW5EZXBsb3llci5q
YXZhOjYwNSkNCj4gCWF0IHN1bi5yZWZsZWN0LkdlbmVyYXRlZE1ldGhvZEFjY2Vzc29yMTYuaW52
b2tlKFVua25vd24gU291cmNlKQ0KPiAJYXQgDQo+IHN1bi5yZWZsZWN0LkRlbGVnYXRpbmdNZXRo
b2RBY2Nlc3NvckltcGwuaW52b2tlKERlbGVnYXRpbmdNZXRoDQo+IG9kQWNjZXNzb3JJbXBsDQo+
IC5qYXZhOjI1KQ0KPiAJYXQgamF2YS5sYW5nLnJlZmxlY3QuTWV0aG9kLmludm9rZShNZXRob2Qu
amF2YTozMjQpDQo+IAlhdCANCj4gb3JnLmpib3NzLm14LmNhcGFiaWxpdHkuUmVmbGVjdGVkTUJl
YW5EaXNwYXRjaGVyLmludm9rZShSZWZsZWMNCj4gdGVkTUJlYW5EaXNwYXQNCj4gY2hlci5qYXZh
OjI4NCkNCj4gCWF0DQo+IG9yZy5qYm9zcy5teC5zZXJ2ZXIuTUJlYW5TZXJ2ZXJJbXBsLmludm9r
ZShNQmVhblNlcnZlckltcGwuamF2YTo1NDYpDQo+IAlhdCANCj4gb3JnLmpib3NzLm14LnV0aWwu
TUJlYW5Qcm94eUV4dC5pbnZva2UoTUJlYW5Qcm94eUV4dC5qYXZhOjE3NykNCj4gCWF0ICRQcm94
eTYuZGVwbG95KFVua25vd24gU291cmNlKQ0KPiAJYXQgDQo+IG9yZy5qYm9zcy5kZXBsb3ltZW50
LnNjYW5uZXIuVVJMRGVwbG95bWVudFNjYW5uZXIuZGVwbG95KFVSTERlDQo+IHBsb3ltZW50U2Nh
bm5lDQo+IHIuamF2YTozMDIpDQo+IAlhdCANCj4gb3JnLmpib3NzLmRlcGxveW1lbnQuc2Nhbm5l
ci5VUkxEZXBsb3ltZW50U2Nhbm5lci5zY2FuKFVSTERlcGwNCj4gb3ltZW50U2Nhbm5lci4NCj4g
amF2YTo0NzYpDQo+IAlhdCANCj4gb3JnLmpib3NzLmRlcGxveW1lbnQuc2Nhbm5lci5BYnN0cmFj
dERlcGxveW1lbnRTY2FubmVyJFNjYW5uZXINCj4gVGhyZWFkLmRvU2NhbigNCj4gQWJzdHJhY3RE
ZXBsb3ltZW50U2Nhbm5lci5qYXZhOjIwMSkNCj4gCWF0IA0KPiBvcmcuamJvc3MuZGVwbG95bWVu
dC5zY2FubmVyLkFic3RyYWN0RGVwbG95bWVudFNjYW5uZXIuc3RhcnRTZQ0KPiBydmljZShBYnN0
cmFjdA0KPiBEZXBsb3ltZW50U2Nhbm5lci5qYXZhOjI3NCkNCj4gCWF0DQo+IG9yZy5qYm9zcy5z
eXN0ZW0uU2VydmljZU1CZWFuU3VwcG9ydC5zdGFydChTZXJ2aWNlTUJlYW5TdXBwb3J0DQo+IC5q
YXZhOjE5MikNCj4gCWF0IHN1bi5yZWZsZWN0LkdlbmVyYXRlZE1ldGhvZEFjY2Vzc29yNC5pbnZv
a2UoVW5rbm93biBTb3VyY2UpDQo+IAlhdCANCj4gc3VuLnJlZmxlY3QuRGVsZWdhdGluZ01ldGhv
ZEFjY2Vzc29ySW1wbC5pbnZva2UoRGVsZWdhdGluZ01ldGgNCj4gb2RBY2Nlc3NvckltcGwNCj4g
LmphdmE6MjUpDQo+IAlhdCBqYXZhLmxhbmcucmVmbGVjdC5NZXRob2QuaW52b2tlKE1ldGhvZC5q
YXZhOjMyNCkNCj4gCWF0IA0KPiBvcmcuamJvc3MubXguY2FwYWJpbGl0eS5SZWZsZWN0ZWRNQmVh
bkRpc3BhdGNoZXIuaW52b2tlKFJlZmxlYw0KPiB0ZWRNQmVhbkRpc3BhdA0KPiBjaGVyLmphdmE6
Mjg0KQ0KPiAJYXQNCj4gb3JnLmpib3NzLm14LnNlcnZlci5NQmVhblNlcnZlckltcGwuaW52b2tl
KE1CZWFuU2VydmVySW1wbC5qYXZhOjU0NikNCj4gCWF0IA0KPiBvcmcuamJvc3Muc3lzdGVtLlNl
cnZpY2VDb250cm9sbGVyJFNlcnZpY2VQcm94eS5pbnZva2UoU2VydmljZQ0KPiBDb250cm9sbGVy
Lmphdg0KPiBhOjk3NikNCj4gCWF0ICRQcm94eTAuc3RhcnQoVW5rbm93biBTb3VyY2UpDQo+IAlh
dA0KPiBvcmcuamJvc3Muc3lzdGVtLlNlcnZpY2VDb250cm9sbGVyLnN0YXJ0KFNlcnZpY2VDb250
cm9sbGVyLmphdmE6Mzk0KQ0KPiAJYXQgc3VuLnJlZmxlY3QuR2VuZXJhdGVkTWV0aG9kQWNjZXNz
b3I1Lmludm9rZShVbmtub3duIFNvdXJjZSkNCj4gCWF0IA0KPiBzdW4ucmVmbGVjdC5EZWxlZ2F0
aW5nTWV0aG9kQWNjZXNzb3JJbXBsLmludm9rZShEZWxlZ2F0aW5nTWV0aA0KPiBvZEFjY2Vzc29y
SW1wbA0KPiAuamF2YToyNSkNCj4gCWF0IGphdmEubGFuZy5yZWZsZWN0Lk1ldGhvZC5pbnZva2Uo
TWV0aG9kLmphdmE6MzI0KQ0KPiAJYXQgDQo+IG9yZy5qYm9zcy5teC5jYXBhYmlsaXR5LlJlZmxl
Y3RlZE1CZWFuRGlzcGF0Y2hlci5pbnZva2UoUmVmbGVjDQo+IHRlZE1CZWFuRGlzcGF0DQo+IGNo
ZXIuamF2YToyODQpDQo+IAlhdA0KPiBvcmcuamJvc3MubXguc2VydmVyLk1CZWFuU2VydmVySW1w
bC5pbnZva2UoTUJlYW5TZXJ2ZXJJbXBsLmphdmE6NTQ2KQ0KPiAJYXQgDQo+IG9yZy5qYm9zcy5t
eC51dGlsLk1CZWFuUHJveHlFeHQuaW52b2tlKE1CZWFuUHJveHlFeHQuamF2YToxNzcpDQo+IAlh
dCAkUHJveHk0LnN0YXJ0KFVua25vd24gU291cmNlKQ0KPiAJYXQgb3JnLmpib3NzLmRlcGxveW1l
bnQuU0FSRGVwbG95ZXIuc3RhcnQoU0FSRGVwbG95ZXIuamF2YToyMjYpDQo+IAlhdCANCj4gb3Jn
Lmpib3NzLmRlcGxveW1lbnQuTWFpbkRlcGxveWVyLnN0YXJ0KE1haW5EZXBsb3llci5qYXZhOjgz
MikNCj4gCWF0IA0KPiBvcmcuamJvc3MuZGVwbG95bWVudC5NYWluRGVwbG95ZXIuZGVwbG95KE1h
aW5EZXBsb3llci5qYXZhOjY0MikNCj4gCWF0IA0KPiBvcmcuamJvc3MuZGVwbG95bWVudC5NYWlu
RGVwbG95ZXIuZGVwbG95KE1haW5EZXBsb3llci5qYXZhOjYwNSkNCj4gCWF0IA0KPiBvcmcuamJv
c3MuZGVwbG95bWVudC5NYWluRGVwbG95ZXIuZGVwbG95KE1haW5EZXBsb3llci5qYXZhOjU4OSkN
Cj4gCWF0IHN1bi5yZWZsZWN0Lk5hdGl2ZU1ldGhvZEFjY2Vzc29ySW1wbC5pbnZva2UwKE5hdGl2
ZSBNZXRob2QpDQo+IAlhdCANCj4gc3VuLnJlZmxlY3QuTmF0aXZlTWV0aG9kQWNjZXNzb3JJbXBs
Lmludm9rZShOYXRpdmVNZXRob2RBY2Nlc3MNCj4gb3JJbXBsLmphdmE6MzkNCj4gKQ0KPiAJYXQg
DQo+IHN1bi5yZWZsZWN0LkRlbGVnYXRpbmdNZXRob2RBY2Nlc3NvckltcGwuaW52b2tlKERlbGVn
YXRpbmdNZXRoDQo+IG9kQWNjZXNzb3JJbXBsDQo+IC5qYXZhOjI1KQ0KPiAJYXQgamF2YS5sYW5n
LnJlZmxlY3QuTWV0aG9kLmludm9rZShNZXRob2QuamF2YTozMjQpDQo+IAlhdCANCj4gb3JnLmpi
b3NzLm14LmNhcGFiaWxpdHkuUmVmbGVjdGVkTUJlYW5EaXNwYXRjaGVyLmludm9rZShSZWZsZWMN
Cj4gdGVkTUJlYW5EaXNwYXQNCj4gY2hlci5qYXZhOjI4NCkNCj4gCWF0DQo+IG9yZy5qYm9zcy5t
eC5zZXJ2ZXIuTUJlYW5TZXJ2ZXJJbXBsLmludm9rZShNQmVhblNlcnZlckltcGwuamF2YTo1NDYp
DQo+IAlhdCANCj4gb3JnLmpib3NzLm14LnV0aWwuTUJlYW5Qcm94eUV4dC5pbnZva2UoTUJlYW5Q
cm94eUV4dC5qYXZhOjE3NykNCj4gCWF0ICRQcm94eTUuZGVwbG95KFVua25vd24gU291cmNlKQ0K
PiAJYXQgDQo+IG9yZy5qYm9zcy5zeXN0ZW0uc2VydmVyLlNlcnZlckltcGwuZG9TdGFydChTZXJ2
ZXJJbXBsLmphdmE6Mzg0KQ0KPiAJYXQgb3JnLmpib3NzLnN5c3RlbS5zZXJ2ZXIuU2VydmVySW1w
bC5zdGFydChTZXJ2ZXJJbXBsLmphdmE6MjkxKQ0KPiAJYXQgb3JnLmpib3NzLk1haW4uYm9vdChN
YWluLmphdmE6MTUwKQ0KPiAJYXQgb3JnLmpib3NzLk1haW4kMS5ydW4oTWFpbi5qYXZhOjM5NSkN
Cj4gCWF0IGphdmEubGFuZy5UaHJlYWQucnVuKFRocmVhZC5qYXZhOjUzNCkNCj4gQ2F1c2VkIGJ5
OiBqYXZhLmxhbmcuSWxsZWdhbFN0YXRlRXhjZXB0aW9uOiBObyANCj4gV2ViQXBwbGljYXRpb25D
b250ZXh0IGZvdW5kOiBubyBDb250ZXh0TG9hZGVyTGlzdGVuZXIgcmVnaXN0ZXJlZD8NCj4gCWF0
IA0KPiBvcmcuc3ByaW5nZnJhbWV3b3JrLndlYi5jb250ZXh0LnN1cHBvcnQuV2ViQXBwbGljYXRp
b25Db250ZXh0VQ0KPiB0aWxzLmdldFJlcXVpcg0KPiBlZFdlYkFwcGxpY2F0aW9uQ29udGV4dChX
ZWJBcHBsaWNhdGlvbkNvbnRleHRVdGlscy5qYXZhOjU2KQ0KPiAJYXQgDQo+IG9yZy5zcHJpbmdm
cmFtZXdvcmsud2ViLmNvbnRleHQuQ29udGV4dExvYWRlci5jbG9zZUNvbnRleHQoQ29uDQo+IHRl
eHRMb2FkZXIuamF2DQo+IGE6MTUzKQ0KPiAJYXQgDQo+IG9yZy5zcHJpbmdmcmFtZXdvcmsud2Vi
LmNvbnRleHQuQ29udGV4dExvYWRlckxpc3RlbmVyLmNvbnRleHREDQo+IGVzdHJveWVkKENvbnRl
DQo+IHh0TG9hZGVyTGlzdGVuZXIuamF2YTo0NykNCj4gCWF0IA0KPiBvcmcubW9ydGJheS5qZXR0
eS5zZXJ2bGV0LldlYkFwcGxpY2F0aW9uQ29udGV4dC5zdG9wKFdlYkFwcGxpYw0KPiBhdGlvbkNv
bnRleHQuag0KPiBhdmE6NDg1KQ0KPiAJYXQgb3JnLm1vcnRiYXkuaHR0cC5IdHRwQ29udGV4dC5z
dG9wKEh0dHBDb250ZXh0LmphdmE6MTg2NCkNCj4gCWF0IG9yZy5qYm9zcy5qZXR0eS5KZXR0eS51
bmRlcGxveShKZXR0eS5qYXZhOjM3MykNCj4gCS4uLiA1MiBtb3JlDQo+IE4YSFnetemailgndeGC
vHrIrXBqeuGvt8eiXhXhuKstSg0KPiDhtonfig0KPiBq2KjGp2ogentSDQo+IF564bm4b2p3HnXa
nWLhoZ4gGitieg0KPiB1aCcceiQnT++plV8WEualhmkw4oCUfnlVJn7hrop7aGkgawhtVCl+6bam
ew0KPiAr1696Wil6WFgqa3gfxaB1ZN6WXlgo4bm6Hn56d+6thmnhgbNs4aWycSAgeh9sLlgp36Mp
KSh+ew0KPiAr1696WikNCj4gDQo+IA0KPiANCg==

RE: [Springframework-developer] Web app deployment error after up grading from m3 to m4

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

Colin,

as I said, I had similar problem due to BeansInstantiationException being
thrown during BeanFactory bootstrap. Just need to see the rest of the stack
trace with "the root cause"

Regards,
Dmitriy.

-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...] 
Sent: Friday, January 09, 2004 10:55 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Web app deployment error after
upgrading from m3 to m4


Alastair,

This is quite strange. I don't know what's going on, but for whatever 
reason it looks like the listener which is supposed to load the context 
is not kicking in for you any longer.

I would take a look in the log first to see if there are any logging 
statements from ContextLoader, as there shoiuld be. If that doesn't 
provide any clues, probably the easiest thing to do is start JBoss with 
the JPDA (debugger) option in the run file, and attach to it with your 
debugger, with a breakpoint on ContextLoaderListener to see if it's 
running at all


Alastair Rodgers wrote:

>Hi,
>
>I just tried to upgrade from m3 to m4 but get an error when I try to 
>deploy my web app. The web app has a context loader listener defined with:
>
>  <context-param>
>    <param-name>contextConfigLocation</param-name>
>    
>
<param-value>/WEB-INF/applicationContext-core.xml,/WEB-INF/applicationContex
t-web.xml</param-value>
>  </context-param>
>
>  <listener>
>    
>
<listener-class>org.springframework.web.context.ContextLoaderListener</liste
ner-class>
>  </listener>
>
>When I try to deploy it I get an exception saying "No 
>WebApplicationContext found: no ContextLoaderListener registered?" 
>(stacktrace below). This app worked fine with Spring m3, and the 
>examples provided with m4 seem to indicate this should be OK. Any idea 
>what the problem is?
>
>Regards,
>Al.
>
>
>org.jboss.deployment.DeploymentException: No WebApplicationContext found:
no ContextLoaderListener registered?; - nested throwable:
(java.lang.IllegalStateException: No WebApplicationContext found: no
ContextLoaderListener registered?)
>	at org.jboss.jetty.Jetty.undeploy(Jetty.java:381)
>	at org.jboss.jetty.Jetty.deploy(Jetty.java:351)
>	at org.jboss.jetty.JettyService.performDeploy(JettyService.java:242)
>	at
org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:428)
>	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:832)
>	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
>	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:642)
>	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:605)
>	at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
>	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
>	at java.lang.reflect.Method.invoke(Method.java:324)
>	at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat
cher.java:284)
>	at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
>	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
>	at $Proxy6.deploy(Unknown Source)
>	at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanne
r.java:302)
>	at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.
java:476)
>	at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(
AbstractDeploymentScanner.java:201)
>	at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(Abstract
DeploymentScanner.java:274)
>	at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192)
>	at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
>	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
>	at java.lang.reflect.Method.invoke(Method.java:324)
>	at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat
cher.java:284)
>	at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
>	at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav
a:976)
>	at $Proxy0.start(Unknown Source)
>	at
org.jboss.system.ServiceController.start(ServiceController.java:394)
>	at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
>	at java.lang.reflect.Method.invoke(Method.java:324)
>	at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat
cher.java:284)
>	at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
>	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
>	at $Proxy4.start(Unknown Source)
>	at org.jboss.deployment.SARDeployer.start(SARDeployer.java:226)
>	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:832)
>	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:642)
>	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:605)
>	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:589)
>	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
>	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
>	at java.lang.reflect.Method.invoke(Method.java:324)
>	at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat
cher.java:284)
>	at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
>	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
>	at $Proxy5.deploy(Unknown Source)
>	at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:384)
>	at org.jboss.system.server.ServerImpl.start(ServerImpl.java:291)
>	at org.jboss.Main.boot(Main.java:150)
>	at org.jboss.Main$1.run(Main.java:395)
>	at java.lang.Thread.run(Thread.java:534)
>Caused by: java.lang.IllegalStateException: No WebApplicationContext found:
no ContextLoaderListener registered?
>	at
org.springframework.web.context.support.WebApplicationContextUtils.getRequir
edWebApplicationContext(WebApplicationContextUtils.java:56)
>	at
org.springframework.web.context.ContextLoader.closeContext(ContextLoader.jav
a:153)
>	at
org.springframework.web.context.ContextLoaderListener.contextDestroyed(Conte
xtLoaderListener.java:47)
>	at
org.mortbay.jetty.servlet.WebApplicationContext.stop(WebApplicationContext.j
ava:485)
>	at org.mortbay.http.HttpContext.stop(HttpContext.java:1864)
>	at org.jboss.jetty.Jetty.undeploy(Jetty.java:373)
>	... 52 more
>N?HY޵隊X???'???u??z??ǒ??pj??z??Ǣ??^?-J????
>?ߊ
?jب?Ƨj ?z{R??^???z????ojwu?ڝ?b?
???+bzƧu?h?'???z?'?O???_???????i??0—?~??y?&???~??{?hi?k?m?T??)?~??{
>+?ׯzZ)z???X??X??*k?x???Š?u?ޖ?^?X???(??~??zw???i????l???q?? 
>+?z???l?X??)ߣ?)?)?~??{ ?ׯzZ)er==
>




-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms. Free
Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Web app deployment error after upgrading from m3 to m4

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

Alastair,

This is quite strange. I don't know what's going on, but for whatever=20
reason it looks like the listener which is supposed to load the context=20
is not kicking in for you any longer.

I would take a look in the log first to see if there are any logging=20
statements from ContextLoader, as there shoiuld be. If that doesn't=20
provide any clues, probably the easiest thing to do is start JBoss with=20
the JPDA (debugger) option in the run file, and attach to it with your=20
debugger, with a breakpoint on ContextLoaderListener to see if it's=20
running at all


Alastair Rodgers wrote:

>Hi,=20
>
>I just tried to upgrade from m3 to m4 but get an error when I try to dep=
loy my web app. The web app has a context loader listener defined with:=20
>
>  <context-param>
>    <param-name>contextConfigLocation</param-name>
>    <param-value>/WEB-INF/applicationContext-core.xml,/WEB-INF/applicati=
onContext-web.xml</param-value>
>  </context-param>
>
>  <listener>
>    <listener-class>org.springframework.web.context.ContextLoaderListene=
r</listener-class>
>  </listener>
>
>When I try to deploy it I get an exception saying "No WebApplicationCont=
ext found: no ContextLoaderListener registered?" (stacktrace below). This=
 app worked fine with Spring m3, and the examples provided with m4 seem t=
o indicate this should be OK. Any idea what the problem is?
>
>Regards,
>Al.
>
>
>org.jboss.deployment.DeploymentException: No WebApplicationContext found=
: no ContextLoaderListener registered?; - nested throwable: (java.lang.Il=
legalStateException: No WebApplicationContext found: no ContextLoaderList=
ener registered?)
>	at org.jboss.jetty.Jetty.undeploy(Jetty.java:381)
>	at org.jboss.jetty.Jetty.deploy(Jetty.java:351)
>	at org.jboss.jetty.JettyService.performDeploy(JettyService.java:242)
>	at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:4=
28)
>	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:832)
>	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
>	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:642)
>	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:605)
>	at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
>	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce=
ssorImpl.java:25)
>	at java.lang.reflect.Method.invoke(Method.java:324)
>	at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBe=
anDispatcher.java:284)
>	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
>	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
>	at $Proxy6.deploy(Unknown Source)
>	at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeployme=
ntScanner.java:302)
>	at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeployment=
Scanner.java:476)
>	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread=
.doScan(AbstractDeploymentScanner.java:201)
>	at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(=
AbstractDeploymentScanner.java:274)
>	at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:=
192)
>	at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
>	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce=
ssorImpl.java:25)
>	at java.lang.reflect.Method.invoke(Method.java:324)
>	at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBe=
anDispatcher.java:284)
>	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
>	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceContro=
ller.java:976)
>	at $Proxy0.start(Unknown Source)
>	at org.jboss.system.ServiceController.start(ServiceController.java:394)
>	at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce=
ssorImpl.java:25)
>	at java.lang.reflect.Method.invoke(Method.java:324)
>	at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBe=
anDispatcher.java:284)
>	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
>	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
>	at $Proxy4.start(Unknown Source)
>	at org.jboss.deployment.SARDeployer.start(SARDeployer.java:226)
>	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:832)
>	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:642)
>	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:605)
>	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:589)
>	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl=
.java:39)
>	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce=
ssorImpl.java:25)
>	at java.lang.reflect.Method.invoke(Method.java:324)
>	at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBe=
anDispatcher.java:284)
>	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
>	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
>	at $Proxy5.deploy(Unknown Source)
>	at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:384)
>	at org.jboss.system.server.ServerImpl.start(ServerImpl.java:291)
>	at org.jboss.Main.boot(Main.java:150)
>	at org.jboss.Main$1.run(Main.java:395)
>	at java.lang.Thread.run(Thread.java:534)
>Caused by: java.lang.IllegalStateException: No WebApplicationContext fou=
nd: no ContextLoaderListener registered?
>	at org.springframework.web.context.support.WebApplicationContextUtils.g=
etRequiredWebApplicationContext(WebApplicationContextUtils.java:56)
>	at org.springframework.web.context.ContextLoader.closeContext(ContextLo=
ader.java:153)
>	at org.springframework.web.context.ContextLoaderListener.contextDestroy=
ed(ContextLoaderListener.java:47)
>	at org.mortbay.jetty.servlet.WebApplicationContext.stop(WebApplicationC=
ontext.java:485)
>	at org.mortbay.http.HttpContext.stop(HttpContext.java:1864)
>	at org.jboss.jetty.Jetty.undeploy(Jetty.java:373)
>	... 52 more
>N=18?HY=DE=B5=E9=9A=8AX???'???u??z??=C7=92??pj??z??=C7=A2??^=15?-J????
>?=DF=8A=0B?j=D8=A8?=C6=A7j=07?z{R??^???z????ojw=1Eu?=DA=9D?b?=07=1A???+b=
z=C6=A7u?h?'=1C???z?'?O???_???=16??=12??i??0=C2=97?~??y?&???~??{?hi?k?=08=
m?T??)?~??{
>+?=D7=AFzZ)z???X??X??*k?x=1F???=C2=8A?u?=DE=96?^?X???(??=1E~??zw???i????=
l???q??=07?z???l?X??)=DF=A3?)?)?~??{
>+?=D7=AFzZ)er=3D=3D
>

RE: [Springframework-developer] Web app deployment error after up grading from m3 to m4

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

Al.,

what is the rest of your stack trace? It's probably caused by some exception
during bean initialization in your application context.

Regards,
Dmitriy.

-----Original Message-----
From: Alastair Rodgers [mailto:ala...@ph...] 
Sent: Friday, January 09, 2004 10:41 AM
To: spr...@li...
Subject: [Springframework-developer] Web app deployment error after
upgrading from m3 to m4


Hi, 

I just tried to upgrade from m3 to m4 but get an error when I try to deploy
my web app. The web app has a context loader listener defined with: 

  <context-param>
    <param-name>contextConfigLocation</param-name>
 
<param-value>/WEB-INF/applicationContext-core.xml,/WEB-INF/applicationContex
t-web.xml</param-value>
  </context-param>

  <listener>
 
<listener-class>org.springframework.web.context.ContextLoaderListener</liste
ner-class>
  </listener>

When I try to deploy it I get an exception saying "No WebApplicationContext
found: no ContextLoaderListener registered?" (stacktrace below). This app
worked fine with Spring m3, and the examples provided with m4 seem to
indicate this should be OK. Any idea what the problem is?

Regards,
Al.


org.jboss.deployment.DeploymentException: No WebApplicationContext found: no
ContextLoaderListener registered?; - nested throwable:
(java.lang.IllegalStateException: No WebApplicationContext found: no
ContextLoaderListener registered?)
	at org.jboss.jetty.Jetty.undeploy(Jetty.java:381)
	at org.jboss.jetty.Jetty.deploy(Jetty.java:351)
	at org.jboss.jetty.JettyService.performDeploy(JettyService.java:242)
	at
org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:428)
	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:832)
	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:642)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:605)
	at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat
cher.java:284)
	at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
	at $Proxy6.deploy(Unknown Source)
	at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanne
r.java:302)
	at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.
java:476)
	at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(
AbstractDeploymentScanner.java:201)
	at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(Abstract
DeploymentScanner.java:274)
	at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192)
	at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat
cher.java:284)
	at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
	at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav
a:976)
	at $Proxy0.start(Unknown Source)
	at
org.jboss.system.ServiceController.start(ServiceController.java:394)
	at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat
cher.java:284)
	at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
	at $Proxy4.start(Unknown Source)
	at org.jboss.deployment.SARDeployer.start(SARDeployer.java:226)
	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:832)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:642)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:605)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:589)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat
cher.java:284)
	at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
	at $Proxy5.deploy(Unknown Source)
	at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:384)
	at org.jboss.system.server.ServerImpl.start(ServerImpl.java:291)
	at org.jboss.Main.boot(Main.java:150)
	at org.jboss.Main$1.run(Main.java:395)
	at java.lang.Thread.run(Thread.java:534)
Caused by: java.lang.IllegalStateException: No WebApplicationContext found:
no ContextLoaderListener registered?
	at
org.springframework.web.context.support.WebApplicationContextUtils.getRequir
edWebApplicationContext(WebApplicationContextUtils.java:56)
	at
org.springframework.web.context.ContextLoader.closeContext(ContextLoader.jav
a:153)
	at
org.springframework.web.context.ContextLoaderListener.contextDestroyed(Conte
xtLoaderListener.java:47)
	at
org.mortbay.jetty.servlet.WebApplicationContext.stop(WebApplicationContext.j
ava:485)
	at org.mortbay.http.HttpContext.stop(HttpContext.java:1864)
	at org.jboss.jetty.Jetty.undeploy(Jetty.java:373)
	... 52 more
NHY޵隊X'uႼzȭpjz᯷Ǣ^ḫ-J
ᶉߊ
jبƧj z{R
^zṸojwuڝbᡞ +bz
uh'z$'O突_楆i0—~yU&~ᮊ{hi kmT)~鶦{
+ׯzZ)zXX*kxŠudޖ^X(Ṻ~zwiၳlᥲq  zl.X)ߣ))(~{
+ׯzZ)

[Springframework-developer] Web app deployment error after upgrading from m3 to m4

[Alastair R. <ala...@ph...>]

SGksIA0KDQpJIGp1c3QgdHJpZWQgdG8gdXBncmFkZSBmcm9tIG0zIHRvIG00IGJ1dCBnZXQgYW4g
ZXJyb3Igd2hlbiBJIHRyeSB0byBkZXBsb3kgbXkgd2ViIGFwcC4gVGhlIHdlYiBhcHAgaGFzIGEg
Y29udGV4dCBsb2FkZXIgbGlzdGVuZXIgZGVmaW5lZCB3aXRoOiANCg0KICA8Y29udGV4dC1wYXJh
bT4NCiAgICA8cGFyYW0tbmFtZT5jb250ZXh0Q29uZmlnTG9jYXRpb248L3BhcmFtLW5hbWU+DQog
ICAgPHBhcmFtLXZhbHVlPi9XRUItSU5GL2FwcGxpY2F0aW9uQ29udGV4dC1jb3JlLnhtbCwvV0VC
LUlORi9hcHBsaWNhdGlvbkNvbnRleHQtd2ViLnhtbDwvcGFyYW0tdmFsdWU+DQogIDwvY29udGV4
dC1wYXJhbT4NCg0KICA8bGlzdGVuZXI+DQogICAgPGxpc3RlbmVyLWNsYXNzPm9yZy5zcHJpbmdm
cmFtZXdvcmsud2ViLmNvbnRleHQuQ29udGV4dExvYWRlckxpc3RlbmVyPC9saXN0ZW5lci1jbGFz
cz4NCiAgPC9saXN0ZW5lcj4NCg0KV2hlbiBJIHRyeSB0byBkZXBsb3kgaXQgSSBnZXQgYW4gZXhj
ZXB0aW9uIHNheWluZyAiTm8gV2ViQXBwbGljYXRpb25Db250ZXh0IGZvdW5kOiBubyBDb250ZXh0
TG9hZGVyTGlzdGVuZXIgcmVnaXN0ZXJlZD8iIChzdGFja3RyYWNlIGJlbG93KS4gVGhpcyBhcHAg
d29ya2VkIGZpbmUgd2l0aCBTcHJpbmcgbTMsIGFuZCB0aGUgZXhhbXBsZXMgcHJvdmlkZWQgd2l0
aCBtNCBzZWVtIHRvIGluZGljYXRlIHRoaXMgc2hvdWxkIGJlIE9LLiBBbnkgaWRlYSB3aGF0IHRo
ZSBwcm9ibGVtIGlzPw0KDQpSZWdhcmRzLA0KQWwuDQoNCg0Kb3JnLmpib3NzLmRlcGxveW1lbnQu
RGVwbG95bWVudEV4Y2VwdGlvbjogTm8gV2ViQXBwbGljYXRpb25Db250ZXh0IGZvdW5kOiBubyBD
b250ZXh0TG9hZGVyTGlzdGVuZXIgcmVnaXN0ZXJlZD87IC0gbmVzdGVkIHRocm93YWJsZTogKGph
dmEubGFuZy5JbGxlZ2FsU3RhdGVFeGNlcHRpb246IE5vIFdlYkFwcGxpY2F0aW9uQ29udGV4dCBm
b3VuZDogbm8gQ29udGV4dExvYWRlckxpc3RlbmVyIHJlZ2lzdGVyZWQ/KQ0KCWF0IG9yZy5qYm9z
cy5qZXR0eS5KZXR0eS51bmRlcGxveShKZXR0eS5qYXZhOjM4MSkNCglhdCBvcmcuamJvc3MuamV0
dHkuSmV0dHkuZGVwbG95KEpldHR5LmphdmE6MzUxKQ0KCWF0IG9yZy5qYm9zcy5qZXR0eS5KZXR0
eVNlcnZpY2UucGVyZm9ybURlcGxveShKZXR0eVNlcnZpY2UuamF2YToyNDIpDQoJYXQgb3JnLmpi
b3NzLndlYi5BYnN0cmFjdFdlYkNvbnRhaW5lci5zdGFydChBYnN0cmFjdFdlYkNvbnRhaW5lci5q
YXZhOjQyOCkNCglhdCBvcmcuamJvc3MuZGVwbG95bWVudC5NYWluRGVwbG95ZXIuc3RhcnQoTWFp
bkRlcGxveWVyLmphdmE6ODMyKQ0KCWF0IG9yZy5qYm9zcy5kZXBsb3ltZW50Lk1haW5EZXBsb3ll
ci5zdGFydChNYWluRGVwbG95ZXIuamF2YTo4MjQpDQoJYXQgb3JnLmpib3NzLmRlcGxveW1lbnQu
TWFpbkRlcGxveWVyLmRlcGxveShNYWluRGVwbG95ZXIuamF2YTo2NDIpDQoJYXQgb3JnLmpib3Nz
LmRlcGxveW1lbnQuTWFpbkRlcGxveWVyLmRlcGxveShNYWluRGVwbG95ZXIuamF2YTo2MDUpDQoJ
YXQgc3VuLnJlZmxlY3QuR2VuZXJhdGVkTWV0aG9kQWNjZXNzb3IxNi5pbnZva2UoVW5rbm93biBT
b3VyY2UpDQoJYXQgc3VuLnJlZmxlY3QuRGVsZWdhdGluZ01ldGhvZEFjY2Vzc29ySW1wbC5pbnZv
a2UoRGVsZWdhdGluZ01ldGhvZEFjY2Vzc29ySW1wbC5qYXZhOjI1KQ0KCWF0IGphdmEubGFuZy5y
ZWZsZWN0Lk1ldGhvZC5pbnZva2UoTWV0aG9kLmphdmE6MzI0KQ0KCWF0IG9yZy5qYm9zcy5teC5j
YXBhYmlsaXR5LlJlZmxlY3RlZE1CZWFuRGlzcGF0Y2hlci5pbnZva2UoUmVmbGVjdGVkTUJlYW5E
aXNwYXRjaGVyLmphdmE6Mjg0KQ0KCWF0IG9yZy5qYm9zcy5teC5zZXJ2ZXIuTUJlYW5TZXJ2ZXJJ
bXBsLmludm9rZShNQmVhblNlcnZlckltcGwuamF2YTo1NDYpDQoJYXQgb3JnLmpib3NzLm14LnV0
aWwuTUJlYW5Qcm94eUV4dC5pbnZva2UoTUJlYW5Qcm94eUV4dC5qYXZhOjE3NykNCglhdCAkUHJv
eHk2LmRlcGxveShVbmtub3duIFNvdXJjZSkNCglhdCBvcmcuamJvc3MuZGVwbG95bWVudC5zY2Fu
bmVyLlVSTERlcGxveW1lbnRTY2FubmVyLmRlcGxveShVUkxEZXBsb3ltZW50U2Nhbm5lci5qYXZh
OjMwMikNCglhdCBvcmcuamJvc3MuZGVwbG95bWVudC5zY2FubmVyLlVSTERlcGxveW1lbnRTY2Fu
bmVyLnNjYW4oVVJMRGVwbG95bWVudFNjYW5uZXIuamF2YTo0NzYpDQoJYXQgb3JnLmpib3NzLmRl
cGxveW1lbnQuc2Nhbm5lci5BYnN0cmFjdERlcGxveW1lbnRTY2FubmVyJFNjYW5uZXJUaHJlYWQu
ZG9TY2FuKEFic3RyYWN0RGVwbG95bWVudFNjYW5uZXIuamF2YToyMDEpDQoJYXQgb3JnLmpib3Nz
LmRlcGxveW1lbnQuc2Nhbm5lci5BYnN0cmFjdERlcGxveW1lbnRTY2FubmVyLnN0YXJ0U2Vydmlj
ZShBYnN0cmFjdERlcGxveW1lbnRTY2FubmVyLmphdmE6Mjc0KQ0KCWF0IG9yZy5qYm9zcy5zeXN0
ZW0uU2VydmljZU1CZWFuU3VwcG9ydC5zdGFydChTZXJ2aWNlTUJlYW5TdXBwb3J0LmphdmE6MTky
KQ0KCWF0IHN1bi5yZWZsZWN0LkdlbmVyYXRlZE1ldGhvZEFjY2Vzc29yNC5pbnZva2UoVW5rbm93
biBTb3VyY2UpDQoJYXQgc3VuLnJlZmxlY3QuRGVsZWdhdGluZ01ldGhvZEFjY2Vzc29ySW1wbC5p
bnZva2UoRGVsZWdhdGluZ01ldGhvZEFjY2Vzc29ySW1wbC5qYXZhOjI1KQ0KCWF0IGphdmEubGFu
Zy5yZWZsZWN0Lk1ldGhvZC5pbnZva2UoTWV0aG9kLmphdmE6MzI0KQ0KCWF0IG9yZy5qYm9zcy5t
eC5jYXBhYmlsaXR5LlJlZmxlY3RlZE1CZWFuRGlzcGF0Y2hlci5pbnZva2UoUmVmbGVjdGVkTUJl
YW5EaXNwYXRjaGVyLmphdmE6Mjg0KQ0KCWF0IG9yZy5qYm9zcy5teC5zZXJ2ZXIuTUJlYW5TZXJ2
ZXJJbXBsLmludm9rZShNQmVhblNlcnZlckltcGwuamF2YTo1NDYpDQoJYXQgb3JnLmpib3NzLnN5
c3RlbS5TZXJ2aWNlQ29udHJvbGxlciRTZXJ2aWNlUHJveHkuaW52b2tlKFNlcnZpY2VDb250cm9s
bGVyLmphdmE6OTc2KQ0KCWF0ICRQcm94eTAuc3RhcnQoVW5rbm93biBTb3VyY2UpDQoJYXQgb3Jn
Lmpib3NzLnN5c3RlbS5TZXJ2aWNlQ29udHJvbGxlci5zdGFydChTZXJ2aWNlQ29udHJvbGxlci5q
YXZhOjM5NCkNCglhdCBzdW4ucmVmbGVjdC5HZW5lcmF0ZWRNZXRob2RBY2Nlc3NvcjUuaW52b2tl
KFVua25vd24gU291cmNlKQ0KCWF0IHN1bi5yZWZsZWN0LkRlbGVnYXRpbmdNZXRob2RBY2Nlc3Nv
ckltcGwuaW52b2tlKERlbGVnYXRpbmdNZXRob2RBY2Nlc3NvckltcGwuamF2YToyNSkNCglhdCBq
YXZhLmxhbmcucmVmbGVjdC5NZXRob2QuaW52b2tlKE1ldGhvZC5qYXZhOjMyNCkNCglhdCBvcmcu
amJvc3MubXguY2FwYWJpbGl0eS5SZWZsZWN0ZWRNQmVhbkRpc3BhdGNoZXIuaW52b2tlKFJlZmxl
Y3RlZE1CZWFuRGlzcGF0Y2hlci5qYXZhOjI4NCkNCglhdCBvcmcuamJvc3MubXguc2VydmVyLk1C
ZWFuU2VydmVySW1wbC5pbnZva2UoTUJlYW5TZXJ2ZXJJbXBsLmphdmE6NTQ2KQ0KCWF0IG9yZy5q
Ym9zcy5teC51dGlsLk1CZWFuUHJveHlFeHQuaW52b2tlKE1CZWFuUHJveHlFeHQuamF2YToxNzcp
DQoJYXQgJFByb3h5NC5zdGFydChVbmtub3duIFNvdXJjZSkNCglhdCBvcmcuamJvc3MuZGVwbG95
bWVudC5TQVJEZXBsb3llci5zdGFydChTQVJEZXBsb3llci5qYXZhOjIyNikNCglhdCBvcmcuamJv
c3MuZGVwbG95bWVudC5NYWluRGVwbG95ZXIuc3RhcnQoTWFpbkRlcGxveWVyLmphdmE6ODMyKQ0K
CWF0IG9yZy5qYm9zcy5kZXBsb3ltZW50Lk1haW5EZXBsb3llci5kZXBsb3koTWFpbkRlcGxveWVy
LmphdmE6NjQyKQ0KCWF0IG9yZy5qYm9zcy5kZXBsb3ltZW50Lk1haW5EZXBsb3llci5kZXBsb3ko
TWFpbkRlcGxveWVyLmphdmE6NjA1KQ0KCWF0IG9yZy5qYm9zcy5kZXBsb3ltZW50Lk1haW5EZXBs
b3llci5kZXBsb3koTWFpbkRlcGxveWVyLmphdmE6NTg5KQ0KCWF0IHN1bi5yZWZsZWN0Lk5hdGl2
ZU1ldGhvZEFjY2Vzc29ySW1wbC5pbnZva2UwKE5hdGl2ZSBNZXRob2QpDQoJYXQgc3VuLnJlZmxl
Y3QuTmF0aXZlTWV0aG9kQWNjZXNzb3JJbXBsLmludm9rZShOYXRpdmVNZXRob2RBY2Nlc3Nvcklt
cGwuamF2YTozOSkNCglhdCBzdW4ucmVmbGVjdC5EZWxlZ2F0aW5nTWV0aG9kQWNjZXNzb3JJbXBs
Lmludm9rZShEZWxlZ2F0aW5nTWV0aG9kQWNjZXNzb3JJbXBsLmphdmE6MjUpDQoJYXQgamF2YS5s
YW5nLnJlZmxlY3QuTWV0aG9kLmludm9rZShNZXRob2QuamF2YTozMjQpDQoJYXQgb3JnLmpib3Nz
Lm14LmNhcGFiaWxpdHkuUmVmbGVjdGVkTUJlYW5EaXNwYXRjaGVyLmludm9rZShSZWZsZWN0ZWRN
QmVhbkRpc3BhdGNoZXIuamF2YToyODQpDQoJYXQgb3JnLmpib3NzLm14LnNlcnZlci5NQmVhblNl
cnZlckltcGwuaW52b2tlKE1CZWFuU2VydmVySW1wbC5qYXZhOjU0NikNCglhdCBvcmcuamJvc3Mu
bXgudXRpbC5NQmVhblByb3h5RXh0Lmludm9rZShNQmVhblByb3h5RXh0LmphdmE6MTc3KQ0KCWF0
ICRQcm94eTUuZGVwbG95KFVua25vd24gU291cmNlKQ0KCWF0IG9yZy5qYm9zcy5zeXN0ZW0uc2Vy
dmVyLlNlcnZlckltcGwuZG9TdGFydChTZXJ2ZXJJbXBsLmphdmE6Mzg0KQ0KCWF0IG9yZy5qYm9z
cy5zeXN0ZW0uc2VydmVyLlNlcnZlckltcGwuc3RhcnQoU2VydmVySW1wbC5qYXZhOjI5MSkNCglh
dCBvcmcuamJvc3MuTWFpbi5ib290KE1haW4uamF2YToxNTApDQoJYXQgb3JnLmpib3NzLk1haW4k
MS5ydW4oTWFpbi5qYXZhOjM5NSkNCglhdCBqYXZhLmxhbmcuVGhyZWFkLnJ1bihUaHJlYWQuamF2
YTo1MzQpDQpDYXVzZWQgYnk6IGphdmEubGFuZy5JbGxlZ2FsU3RhdGVFeGNlcHRpb246IE5vIFdl
YkFwcGxpY2F0aW9uQ29udGV4dCBmb3VuZDogbm8gQ29udGV4dExvYWRlckxpc3RlbmVyIHJlZ2lz
dGVyZWQ/DQoJYXQgb3JnLnNwcmluZ2ZyYW1ld29yay53ZWIuY29udGV4dC5zdXBwb3J0LldlYkFw
cGxpY2F0aW9uQ29udGV4dFV0aWxzLmdldFJlcXVpcmVkV2ViQXBwbGljYXRpb25Db250ZXh0KFdl
YkFwcGxpY2F0aW9uQ29udGV4dFV0aWxzLmphdmE6NTYpDQoJYXQgb3JnLnNwcmluZ2ZyYW1ld29y
ay53ZWIuY29udGV4dC5Db250ZXh0TG9hZGVyLmNsb3NlQ29udGV4dChDb250ZXh0TG9hZGVyLmph
dmE6MTUzKQ0KCWF0IG9yZy5zcHJpbmdmcmFtZXdvcmsud2ViLmNvbnRleHQuQ29udGV4dExvYWRl
ckxpc3RlbmVyLmNvbnRleHREZXN0cm95ZWQoQ29udGV4dExvYWRlckxpc3RlbmVyLmphdmE6NDcp
DQoJYXQgb3JnLm1vcnRiYXkuamV0dHkuc2VydmxldC5XZWJBcHBsaWNhdGlvbkNvbnRleHQuc3Rv
cChXZWJBcHBsaWNhdGlvbkNvbnRleHQuamF2YTo0ODUpDQoJYXQgb3JnLm1vcnRiYXkuaHR0cC5I
dHRwQ29udGV4dC5zdG9wKEh0dHBDb250ZXh0LmphdmE6MTg2NCkNCglhdCBvcmcuamJvc3MuamV0
dHkuSmV0dHkudW5kZXBsb3koSmV0dHkuamF2YTozNzMpDQoJLi4uIDUyIG1vcmUNCg==

Re: [Springframework-developer] Re: Final methods in SqlQuery

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

What I meant regarding JdbcDaoSupport's "jdbcTemplate" property is that =
could also set up your *JdbcTemplate* instance in the application =
context and pass it to your DAOs:
=20
<bean id=3D"myJdbcTemplate" class=3D"mypackage.MyJdbcTemplate">
  <property name=3D"dataSource"><ref bean=3D"dataSource"/></property>
</bean>
=20
<bean id=3D"myDao" class=3D"mypackage.MyDao">
  <property name=3D"jdbcTemplate"><ref =
bean=3D"myJdbcTemplate"/></property>
</bean>
=20
Your DAO class can then still derive from the standard JdbcDaoSupport, =
which offers exactly such a "jdbcTemplate" property. This is not only =
useful for custom JdbcTemplate subclasses but also for common =
JdbcTemplate settings like "exceptionTranslator" and "ignoreWarnings" =
that you just want to set up once and pass to all your DAOs.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Michael Young
Gesendet: Fr 09.01.2004 01:51
An: spr...@li...
Betreff: Re: [Springframework-developer] Re: Final methods in SqlQuery



Juergen,

Since I have my own JdbcTemplate, I have to overwrite the setDataSource =
method
in JdbcDaoSupport to create my own JdbcTemplate instance.  If the
method is not final, I would be able to do so.

But like you said, I can easily create my own dao support class, which
is what I did as a workaround.

Thanks!  --Pinghua

On Monday, Jan-05-2004 05:18 AM (PST) jue...@we... =
(j=FCrgen h=F6ller [werk3AT]) wrote:

> Michael,
>=20
> I can understand your concerns. But JdbcDaoSupport still belongs in =
the main framework: It is not meant to be a base class for customized =
DAO base classes but rather a convenience base class for concrete DAOs. =
In all other cases, use straightforward DAO implementations that expose =
their dependencies, or create your own base class that accepts a =
DataSource and/or JdbcTemplate instance. We should probably clarify this =
in the Javadocs.
>=20
> Why exactly do you want to override JdbcDaoSupport's methods? The only =
thing that I can imagine is using your own subclass of JdbcTemplate: You =
could achieve this easily by setting up your JdbcTemplate instance in =
the application context and passing it to JdbcDaoSupport's =
"jdbcTemplate" property - actually, pre-configured JdbcTemplate =
instances is exactly what that property is for.
>=20
> JdbcDaoSupport is really a *very simple* convenience base class for =
standard JDBC-based DAOs, so I don't consider it inappropriate to create =
your own class here... (your own class can even derive from any other =
base class then). And if you don't set a pre-configured JdbcTemplate =
anyway, you just need setDataSource and getJdbcTemplate methods.For =
example, with a custom subclass of JdbcTemplate:
>=20
> public abstract class MyJdbcDaoSupport {
>=20
>   private JdbcTemplate jdbcTemplate;
>=20
>   public final void setDataSource(DataSource dataSource) {
>     this.jdbcTemplate =3D new MyJdbcTemplate(dataSource);
>   }
>=20
>   protected final getJdbcTemplate() {
>     return jdbcTemplate;
>   }
> }
>=20
> The same applies to HibernateDaoSupport, JdoDaoSupport, and =
SqlMapDaoSupport: They are all supposed to serve as convenience DAO base =
classes for *typical* scenarios, to be replaced by custom base classes =
or no base classes at all in case of special requirements.
>=20
> Juergen
>=20
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
von Michael Young
> Gesendet: So 04.01.2004 19:54
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Re: Final methods in SqlQuery
>
>
>
> Rod,
>
> Sorry about my confusion.  Actually, what I had to work around
> JdbcTemplate is not the issue of final methods.  There aren't
> any final methods in JdbcTemplate that I want to overwrite.
>
> My issue was the following:
>
> I want to overwrite afterPropertiesSet() in JdbcTemplate so that
> it won't call getExceptionTranslator() immediately when a
> datasource is being set.  This is because my datasource is a wrapper
> for a bunch of datasources, so the real datasource is not known
> until it's actually used.
>
> This is why I have to overwrite afterPropertiesSet() in my subclass
> of JdbcTemplate.
>
> I was also using JdbcDaoSupport but its JavaBean set and get methods
> are all final, and this is the issue I was complaining.  I have to
> create my own class rather than extending from JdbcDaoSupport.  This
> is OK, but I really don't like the idea of methods being final
> when there are no such needs/benefits from it.  JdbcDaoSupport is
> not a crucial class in the framework, but that doesn't mean that
> we shouldn't take care of it just like those important classes
> in the framework.  It may be a trivial and unimportant class to
> you, but it was important to me because I was using it.  And it
> may be important to others as well.  If we are supposed to write
> our own rather than extending from it, then maybe it should not
> belong there.  Maybe it should be in one of those sample apps.
>
> I'm not really complaining, but just hope for improvements in Spring.
>
> Thanks!  /Michael.
>
> On Friday, Jan-02-2004 10:12 AM (PST) rod...@in... (Rod =
Johnson) wrote:
>
> > I don't object to making more methods non-final, as people do ask =
for this.
> >
> > However, in general I think there are better extension mechanisms =
than
> > overriding methods in Spring in many cases. I don't particularly =
like
> > overriding concrete methods as a means of extensibility.
> >
> > Why would you want to subclass JdbcTemplate?
> >
> > Why would you override JdbcDaoSupport's methods?
> >
> > I'm not being sarcastic, I'm just curious...
> >
> > Regards,
> > Rod
> >
> > ----- Original Message -----
> > From: "Michael Young" <sp...@on...>
> > To: <spr...@li...>
> > Sent: Friday, January 02, 2004 5:42 PM
> > Subject: Re: [Springframework-developer] Re: Final methods in =
SqlQuery
> >
> >
> > Juergen,
> >
> > Can you do the same for other classes as well?  Classes such as
> > JdbcTemplate and JdbcDaoSupport.  Someone also mentioned the
> > abstract wizard form controller as well.  See messages previously
> > posted either here or in users.
> >
> > Thanks!  /Michael.
> >
> > On Friday, Jan-02-2004 02:45 AM (PST) jue...@we... =
(j=FCrgen
> > h=F6ller [werk3AT]) wrote:
> >
> > > This sounds plausible to me. I'll look into turning appropriate =
methods
> > non-final today, if noone objects.
> > >
> > > The original rationale behind the final methods is to offer clear
> > extension points: Subclassers should know which methods are intended =
for
> > overriding and which are not, avoiding confusion. But I agree that =
this
> > doesn't work for cases that the framework developers didn't expect, =
so it's
> > probably better to not use final for methods where there is no clear =
general
> > extension hook. I've already applied the same principle in the bean =
factory
> > implementation hierarchy.
> > >
> > > Juergen
> > >
> > >
> > > ________________________________
> > >
> > > Von: spr...@li... im =
Auftrag von
> > David Heimann
> > > Gesendet: Fr 02.01.2004 02:24
> > > An: spr...@li...
> > > Betreff: [Springframework-developer] Re: Final methods in SqlQuery
> > >
> > >
> > >
> > > Ken and developers,
> > >
> > > I have a business rule in my system that all the data be
> > > stored in upper case in the database.  This sugests the
> > > following design:
> > >
> > > 1)This is a business rule and so should be in the model
> > > layer rather than the presentation layer
> > >
> > > 2)The code to upper case the data should be centralized.
> > > Requiring each developer to upper case the data before
> > > calling the execute or update methods duplicates code and
> > > is error prone.  (the PetClinic sample has around 12
> > > execute or update calls, each of which would need to be
> > > prefaced by upper casing code)
> > >
> > > 3)This suggests a design where I extend SqlUpdate and
> > > SqlQuery and override the SqlUpdate.update and
> > > SqlQuery.execute methods, for example
> > >
> > > public abstract SqlQueryUpper extends SqlQuery
> > > {
> > >         public List execute(Object[] parameters, Map context)
> > > throws DataAccessException {
> > >                 //upper case string parameters
> > >                 for(int i =3D 0;i<parameters.length;i++)
> > >                 {
> > >                         Object p =3D parameters[i];
> > >                         if(p instanceof java.lang.String)
> > >                         {
> > >                                 parameters[i] =3D p.toUpper();
> > >                         }
> > >                 }
> > >                 return super.execute(parameters, context);
> > >         }
> > > }
> > >
> > > Of course, I could create my own method with a different
> > > name such as
> > >         ...
> > >         public List executeUpper(Object[] parameters, Map context)
> > > throws DataAccessException
> > >         {
> > >                 (same as above)
> > >         }
> > >
> > > But if I do that, then I
> > >         1)Still have the original SqlQuery.execute method out
> > > there which no one should use.
> > >         2)Do not have all the other signatures available such as
> > > SqlQuery.execute(int), SqlQuery.execute(String) etc because
> > > they all still go through the original execute method.
> > >
> > > Finally, my problem is an example of something not included
> > > or anticipated by the developers of the Spring Framework.
> > > There is no built in Spring 'auto-upper' option nor should
> > > there be.  Putting final on methods stops me from adding it
> > > myself, making the framework unextendable in this area.
> > > IMHO final methods should be few and far between in an
> > > extensible framework and I do not think they are called for
> > > here.
> > >
> > > Sincerely,
> > >
> > > David Heimann
> > >
> > > >David,
> > >  >
> > > > I don't  understand why you think it would be nice to
> > > ***override*** it.
> > > > The execute method does all the IOC hard stuff for you.
> > > If you override
> > > > it, you have to do this yourself, adding unnecessary
> > > duplication. That's
> > > > why it's final. The same goes for SqlUpdate.update. In
> > > your example, why
> > > > not simply manipulate the parameters to your heart's
> > > content before
> > > > passing them to the execute method ?
> > > >
> > > > Ken
> > > >
> > > > Heimann, David X - San Mateo, CA wrote:
> > > >
> > > > > Developers,
> > > > >
> > > > > Could you change
> > > > >
> > > > > *public** final* List execute(*final* Object[]
> > > parameters, Map context)
> > > > > {
> > > > > ...
> > > > > }
> > > > >
> > > > > in org.springframework.jdbc.object.SqlQuery to not be
> > > final ?  It
> > > > > would be nice to overload it, for example to change all
> > > parameters to
> > > > > upper case before executing.  The similar update method
> > > in SqlUpdate
> > > > > is not final.  Why be final at all ?
> > > > >
> > > > > David Heimann
> > > > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > Find out what made the Top Yahoo! Searches of 2003
> > > http://search.yahoo.com/top2003
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: IBM Linux Tutorials.
> > > Become an expert in LINUX or just sharpen your skills.  Sign up =
for IBM's
> > > Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
> > > Click now! =
http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: IBM Linux Tutorials.
> > > Become an expert in LINUX or just sharpen your skills.  Sign up =
for IBM's
> > > Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
> > > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: Final methods in SqlQuery

[Michael Y. <sp...@on...>]

Juergen,

Since I have my own JdbcTemplate, I have to overwrite the setDataSource met=
hod
in JdbcDaoSupport to create my own JdbcTemplate instance.  If the
method is not final, I would be able to do so.

But like you said, I can easily create my own dao support class, which
is what I did as a workaround.

Thanks!  --Pinghua

On Monday, Jan-05-2004 05:18 AM (PST) jue...@we... (j=FCrgen=
 h=F6ller [werk3AT]) wrote:

> Michael,
> =20
> I can understand your concerns. But JdbcDaoSupport still belongs in the m=
ain framework: It is not meant to be a base class for customized DAO base c=
lasses but rather a convenience base class for concrete DAOs. In all other =
cases, use straightforward DAO implementations that expose their dependenci=
es, or create your own base class that accepts a DataSource and/or JdbcTemp=
late instance. We should probably clarify this in the Javadocs.
> =20
> Why exactly do you want to override JdbcDaoSupport's methods? The only th=
ing that I can imagine is using your own subclass of JdbcTemplate: You coul=
d achieve this easily by setting up your JdbcTemplate instance in the appli=
cation context and passing it to JdbcDaoSupport's "jdbcTemplate" property -=
 actually, pre-configured JdbcTemplate instances is exactly what that prope=
rty is for.
> =20
> JdbcDaoSupport is really a *very simple* convenience base class for stand=
ard JDBC-based DAOs, so I don't consider it inappropriate to create your ow=
n class here... (your own class can even derive from any other base class t=
hen). And if you don't set a pre-configured JdbcTemplate anyway, you just n=
eed setDataSource and getJdbcTemplate methods.For example, with a custom su=
bclass of JdbcTemplate:
> =20
> public abstract class MyJdbcDaoSupport {
> =20
>   private JdbcTemplate jdbcTemplate;
> =20
>   public final void setDataSource(DataSource dataSource) {
>     this.jdbcTemplate =3D new MyJdbcTemplate(dataSource);
>   }
> =20
>   protected final getJdbcTemplate() {
>     return jdbcTemplate;
>   }
> }
> =20
> The same applies to HibernateDaoSupport, JdoDaoSupport, and SqlMapDaoSupp=
ort: They are all supposed to serve as convenience DAO base classes for *ty=
pical* scenarios, to be replaced by custom base classes or no base classes =
at all in case of special requirements.
> =20
> Juergen
> =20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag von=
 Michael Young
> Gesendet: So 04.01.2004 19:54
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Re: Final methods in SqlQuery
>=20
>=20
>=20
> Rod,
>=20
> Sorry about my confusion.  Actually, what I had to work around
> JdbcTemplate is not the issue of final methods.  There aren't
> any final methods in JdbcTemplate that I want to overwrite.
>=20
> My issue was the following:
>=20
> I want to overwrite afterPropertiesSet() in JdbcTemplate so that
> it won't call getExceptionTranslator() immediately when a
> datasource is being set.  This is because my datasource is a wrapper
> for a bunch of datasources, so the real datasource is not known
> until it's actually used.
>=20
> This is why I have to overwrite afterPropertiesSet() in my subclass
> of JdbcTemplate.
>=20
> I was also using JdbcDaoSupport but its JavaBean set and get methods
> are all final, and this is the issue I was complaining.  I have to
> create my own class rather than extending from JdbcDaoSupport.  This
> is OK, but I really don't like the idea of methods being final
> when there are no such needs/benefits from it.  JdbcDaoSupport is
> not a crucial class in the framework, but that doesn't mean that
> we shouldn't take care of it just like those important classes
> in the framework.  It may be a trivial and unimportant class to
> you, but it was important to me because I was using it.  And it
> may be important to others as well.  If we are supposed to write
> our own rather than extending from it, then maybe it should not
> belong there.  Maybe it should be in one of those sample apps.
>=20
> I'm not really complaining, but just hope for improvements in Spring.
>=20
> Thanks!  /Michael.
>=20
> On Friday, Jan-02-2004 10:12 AM (PST) rod...@in... (Rod Jo=
hnson) wrote:
>=20
> > I don't object to making more methods non-final, as people do ask for t=
his.
> >
> > However, in general I think there are better extension mechanisms than
> > overriding methods in Spring in many cases. I don't particularly like
> > overriding concrete methods as a means of extensibility.
> >
> > Why would you want to subclass JdbcTemplate?
> >
> > Why would you override JdbcDaoSupport's methods?
> >
> > I'm not being sarcastic, I'm just curious...
> >
> > Regards,
> > Rod
> >
> > ----- Original Message -----
> > From: "Michael Young" <sp...@on...>
> > To: <spr...@li...>
> > Sent: Friday, January 02, 2004 5:42 PM
> > Subject: Re: [Springframework-developer] Re: Final methods in SqlQuery
> >
> >
> > Juergen,
> >
> > Can you do the same for other classes as well?  Classes such as
> > JdbcTemplate and JdbcDaoSupport.  Someone also mentioned the
> > abstract wizard form controller as well.  See messages previously
> > posted either here or in users.
> >
> > Thanks!  /Michael.
> >
> > On Friday, Jan-02-2004 02:45 AM (PST) jue...@we... (j=FC=
rgen
> > h=F6ller [werk3AT]) wrote:
> >
> > > This sounds plausible to me. I'll look into turning appropriate metho=
ds
> > non-final today, if noone objects.
> > >
> > > The original rationale behind the final methods is to offer clear
> > extension points: Subclassers should know which methods are intended fo=
r
> > overriding and which are not, avoiding confusion. But I agree that this
> > doesn't work for cases that the framework developers didn't expect, so =
it's
> > probably better to not use final for methods where there is no clear ge=
neral
> > extension hook. I've already applied the same principle in the bean fac=
tory
> > implementation hierarchy.
> > >
> > > Juergen
> > >
> > >
> > > ________________________________
> > >
> > > Von: spr...@li... im Auftrag=
 von
> > David Heimann
> > > Gesendet: Fr 02.01.2004 02:24
> > > An: spr...@li...
> > > Betreff: [Springframework-developer] Re: Final methods in SqlQuery
> > >
> > >
> > >
> > > Ken and developers,
> > >
> > > I have a business rule in my system that all the data be
> > > stored in upper case in the database.  This sugests the
> > > following design:
> > >
> > > 1)This is a business rule and so should be in the model
> > > layer rather than the presentation layer
> > >
> > > 2)The code to upper case the data should be centralized.
> > > Requiring each developer to upper case the data before
> > > calling the execute or update methods duplicates code and
> > > is error prone.  (the PetClinic sample has around 12
> > > execute or update calls, each of which would need to be
> > > prefaced by upper casing code)
> > >
> > > 3)This suggests a design where I extend SqlUpdate and
> > > SqlQuery and override the SqlUpdate.update and
> > > SqlQuery.execute methods, for example
> > >
> > > public abstract SqlQueryUpper extends SqlQuery
> > > {
> > >         public List execute(Object[] parameters, Map context)
> > > throws DataAccessException {
> > >                 //upper case string parameters
> > >                 for(int i =3D 0;i<parameters.length;i++)
> > >                 {
> > >                         Object p =3D parameters[i];
> > >                         if(p instanceof java.lang.String)
> > >                         {
> > >                                 parameters[i] =3D p.toUpper();
> > >                         }
> > >                 }
> > >                 return super.execute(parameters, context);
> > >         }
> > > }
> > >
> > > Of course, I could create my own method with a different
> > > name such as
> > >         ...
> > >         public List executeUpper(Object[] parameters, Map context)
> > > throws DataAccessException
> > >         {
> > >                 (same as above)
> > >         }
> > >
> > > But if I do that, then I
> > >         1)Still have the original SqlQuery.execute method out
> > > there which no one should use.
> > >         2)Do not have all the other signatures available such as
> > > SqlQuery.execute(int), SqlQuery.execute(String) etc because
> > > they all still go through the original execute method.
> > >
> > > Finally, my problem is an example of something not included
> > > or anticipated by the developers of the Spring Framework.
> > > There is no built in Spring 'auto-upper' option nor should
> > > there be.  Putting final on methods stops me from adding it
> > > myself, making the framework unextendable in this area.
> > > IMHO final methods should be few and far between in an
> > > extensible framework and I do not think they are called for
> > > here.
> > >
> > > Sincerely,
> > >
> > > David Heimann
> > >
> > > >David,
> > >  >
> > > > I don't  understand why you think it would be nice to
> > > ***override*** it.
> > > > The execute method does all the IOC hard stuff for you.
> > > If you override
> > > > it, you have to do this yourself, adding unnecessary
> > > duplication. That's
> > > > why it's final. The same goes for SqlUpdate.update. In
> > > your example, why
> > > > not simply manipulate the parameters to your heart's
> > > content before
> > > > passing them to the execute method ?
> > > >
> > > > Ken
> > > >
> > > > Heimann, David X - San Mateo, CA wrote:
> > > >
> > > > > Developers,
> > > > >
> > > > > Could you change
> > > > >
> > > > > *public** final* List execute(*final* Object[]
> > > parameters, Map context)
> > > > > {
> > > > > ...
> > > > > }
> > > > >
> > > > > in org.springframework.jdbc.object.SqlQuery to not be
> > > final ?  It
> > > > > would be nice to overload it, for example to change all
> > > parameters to
> > > > > upper case before executing.  The similar update method
> > > in SqlUpdate
> > > > > is not final.  Why be final at all ?
> > > > >
> > > > > David Heimann
> > > > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > Find out what made the Top Yahoo! Searches of 2003
> > > http://search.yahoo.com/top2003
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: IBM Linux Tutorials.
> > > Become an expert in LINUX or just sharpen your skills.  Sign up for I=
BM's
> > > Free Linux Tutorials.  Learn everything from the bash shell to sys ad=
min.
> > > Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dcli=
ck
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-develope=
r
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: IBM Linux Tutorials.
> > > Become an expert in LINUX or just sharpen your skills.  Sign up for I=
BM's
> > > Free Linux Tutorials.  Learn everything from the bash shell to sys ad=
min.
> > > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-develope=
r
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for IBM=
's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys admi=
n.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for IBM=
's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys admi=
n.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] create a bean via BeantUtils.instantiateClass

[Andreas R. <ar...@gm...>]

Hi,

I receive a NullPointerException if I define a Bean in the ApplicationContext 
which constructs a ImageResource like this:

class TestApp {
	private ImageIcon imageHelp = new 
ImageIcon(TestApp.class.getResource("/images/help.gif"));

	// Default Constructor
	public TestApp()
	{
	}
}


This works fine, as long as the image is in the classpath. But if not, then 
the resulting NullPointerException isn't fetched by 
BeanUtils.instantiateClass(Class clazz) and I have to search for the reason 
because it was not directly  clear where is my error.

Is it possible to add something like this to catch all possible Exceptions in 
BeanUtils.instantiateClass(Class clazz)?

-------------------------------------------------------------------------------
		catch (Exception ex){
		    throw new FatalBeanException("Could not instantiate class [" + 
clazz.getName() + "]; Something different",ex);
		}

------------------------------------------------------------------------------

Of course, my programming style should be better :-)

Best regards

			Andreas

[Springframework-developer] automated builds / deployment testing

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

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


hi,

I've amended all of the autobuilds code to use specifically tailored apps
(one is a minimal web app to prove the environment works, the other is a
modified, stripped down jpetstore).  These are sandboxed away from the real
sample apps.

Server configs now exist for resin2, resin3, tomcat4, tomcat5, jetty4 &
jboss3 and I've verified all of them (except jetty which can't read tld's in
jar files) produce no junit errors for the jpetstore sample.

Next step will be to expand the httpunit tests, and change the modified
jpetstore to add more diverse Spring functionality so that the test coverage
is greater.

See the /autobuilds/readme.txt for more info.

Cheers!

- --

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE//UWAKLMLAN01aw0RAqPTAJ9JidgcDcDGKm9Ri0WF8hHjgieBcgCfQ0o/
G/W1VeNDhRT8ugJlm7FAgFo=
=OeqE
-----END PGP SIGNATURE-----

Re: [Springframework-developer] Inappropriate logging level?

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

Good point: I've changed it to info level: As this is about a rollback =
which isn't the normal flow of operation, info is appropriate, IMO. =
After all, production applications typically just log down to warn level =
anyway (no info, debug, trace).
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Oliver Hutchison
Gesendet: Do 08.01.2004 05:45
An: spr...@li...
Betreff: [Springframework-developer] Inappropriate logging level?



Hi,

Just putting this one out there.

// -------- Start Code --------
private void onThrowable(MethodInvocation invocation,
TransactionAttribute txAtt, TransactionStatus status, Throwable ex) {
  if (txAtt.rollbackOn(ex)) {
   logger.error("Invoking rollback for transaction on method '" +
invocation.getMethod().getName() +
                "' due to throwable [" + ex + "]");
   try {
    this.transactionManager.rollback(status);
   }
   catch (TransactionException tex) {
    logger.error("Application exception overridden by rollback
exception", ex);
    throw tex;
   }
  }
  else {
   if (logger.isDebugEnabled())
    logger.debug("Method '" + invocation.getMethod().getName()+ "' threw
throwable [" + ex +
                 "] but this does not force transaction rollback");
   // Will still roll back if rollbackOnly is true
   this.transactionManager.commit(status);
  }
 }
// -------- End Code --------

Is it really appropriate for the TransactionInterceptor.onThrowable(...)
method to log the fact that an exception has caused a rollback at level
ERROR?

I would have thought the ERROR level would only be used in places where
a runtime error or unexpected conditions has been detected. What's
happening in the TransactionInterceptor is exactly what should be
happening given its configuration.

IMHO it should really be at DEBUG or TRACE level.

What do you think?

Ollie


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Inappropriate logging level?

[Oliver H. <Oli...@ou...>]

Hi,

Just putting this one out there.

// -------- Start Code --------
private void onThrowable(MethodInvocation invocation,
TransactionAttribute txAtt, TransactionStatus status, Throwable ex) {
  if (txAtt.rollbackOn(ex)) {
   logger.error("Invoking rollback for transaction on method '" +
invocation.getMethod().getName() +
                "' due to throwable [" + ex + "]");
   try {
    this.transactionManager.rollback(status);
   }
   catch (TransactionException tex) {
    logger.error("Application exception overridden by rollback
exception", ex);
    throw tex;
   }
  }
  else {
   if (logger.isDebugEnabled())
    logger.debug("Method '" + invocation.getMethod().getName()+ "' threw
throwable [" + ex +
                 "] but this does not force transaction rollback");
   // Will still roll back if rollbackOnly is true
   this.transactionManager.commit(status);
  }
 }
// -------- End Code --------

Is it really appropriate for the TransactionInterceptor.onThrowable(...)
method to log the fact that an exception has caused a rollback at level
ERROR?=20

I would have thought the ERROR level would only be used in places where
a runtime error or unexpected conditions has been detected. What's
happening in the TransactionInterceptor is exactly what should be
happening given its configuration.=20

IMHO it should really be at DEBUG or TRACE level.

What do you think?

Ollie

Re: [Springframework-developer] PostProcessor infrastructure in DefaultListableBeanFactory and EJB support classes

[Peter d. H. <pe...@de...>]

Colin Sampaleanu wrote:

> The fact that DefaultListableBeanFactory has some of the support code is
> somewhat irrelevant. The contract is [...]

My apologies, I wasn't at all clear. Although I listed changing way the
BeanFactory works as the first possibility, I don't think that's by any
means the best option. Changing the contract might break existing software
and would not be a good idea at this stage even if it were desirable as
such.

The basic need is for the postprocessors in the BeanFactory to be
initialised; either by modifying XmlBeanFactoryLoader to perform this
initialisation, or through replacing the BeanFactory with a full
ApplicationContext as you suggest. That would be an even better solution but
slightly more of a change. I'd be happy with either :)

Thanks

 - Peter

Re: [lists] Re: [Springframework-developer] PostProcessor infrastructure in DefaultListableBeanFactory and EJB support classes

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

Peter den Haan wrote:

>Colin Sampaleanu wrote:
>
>>eanPostProcessors are a function of ApplicationContexts, so it is
>>normal that BeanFactories which are not also ApplicationContexts (such
>>as that produced by XMLBeanFactoryLoader) do no post-processing.
>>    
>>
>Ah, but that's the funny thing. This is not entirely true. The actual
>postprocessing plumbing is part and parcel of the DefaultListableBeanFactory
>itself. However, it does not auto-register any postprocessors itself. That
>is done by the application context. Given the important place postprocessing
>has been gaining in the Spring infrastructure, it seems odd that EJBs do get
>a BeanFactory that does in fact have all it takes (you do not need a full
>context) but is still very limited because its postprocessing plumbing isn't
>initialised.
>
>Users new to the product would expect Spring to provide some out-of-the-box
>support for a fully functional bean container in the EJB tier, probably by
>default. As things stand, you won't be getting this without coding (and a
>nontrivial understanding of Spring subtleties).
>  
>
The fact that DefaultListableBeanFactory has some of the support code is 
somewhat irrelevant. The contract is that if something has the 
ApplicationContext interface it supports BeanPostProcessors, and if it 
doesn't (i.e. it is simply a BeanFactory), it doesn't support 
BeanPostProcessors. And this is how the current code behaves. As I said, 
I agree that the distinction between application contexts and bean 
factories needs to be better documented, and it probably makes sense for 
the default BeanFactoryLoader in the base EJB classes to produce an 
ApplicationContext variant instead of just a regular BeanFactory. That 
code actually got into Spring before I got to the project, so I'm not 
sure why it was decided one way vs. another. If there is no opposition, 
I am quite willing to make that change...

Regards,
Colin

Re: [Springframework-developer] PostProcessor infrastructure in DefaultListableBeanFactory and EJB support classes

[Peter d. H. <pe...@de...>]

J=FCrgen H=F6ller wrote:

> I'd like to keep the bean factories as-is, mainly for programmatic use
[...]

I wouldn't advocate anything else -- changing the way bean factories work
would break a lot of stuff. The smallest change that could possibly work
would be to modify XmlBeanFactoryLoader to detect and register
postprocessors in the same way that AbstractApplicationContext does. This
would allow all the important Spring plumbing to work out of the box in t=
he
EJB tier, and I don't expect that it would break much (if anything).

Moving the postprocessor registration code to utility methods in BeanFact=
ory
is merely a suggested refactoring to prevent code duplication and would n=
ot
in any way change the way bean factories work.

> An easy way to make post-processors available in EJB implementation
classes would to be to simply load a
> ClassPathXmlApplicationContext instead of an XmlBeanFactory in the
BeanFactoryLoader used. Of course,
> you can always implement such a custom loader yourself, but we can also
consider making this the default loader.

This is slightly more of a change, but would be an excellent option. IMHO
unless there is a strong reason to the contrary the default should be
something that supports postprocessors; either an application context, or=
 a
factory with initialised postprocessors as above.

 - Peter

Re: [lists] Re: [Springframework-developer] PostProcessor infrastructure in DefaultListableBeanFactory and EJB support classes

[Peter d. H. <pe...@de...>]

Colin Sampaleanu wrote:

> BeanPostProcessors are a function of ApplicationContexts, so it is
> normal that BeanFactories which are not also ApplicationContexts (such
> as that produced by XMLBeanFactoryLoader) do no post-processing.

Ah, but that's the funny thing. This is not entirely true. The actual
postprocessing plumbing is part and parcel of the DefaultListableBeanFactory
itself. However, it does not auto-register any postprocessors itself. That
is done by the application context. Given the important place postprocessing
has been gaining in the Spring infrastructure, it seems odd that EJBs do get
a BeanFactory that does in fact have all it takes (you do not need a full
context) but is still very limited because its postprocessing plumbing isn't
initialised.

Users new to the product would expect Spring to provide some out-of-the-box
support for a fully functional bean container in the EJB tier, probably by
default. As things stand, you won't be getting this without coding (and a
nontrivial understanding of Spring subtleties).

 - Peter