springframework-developer — Spring Framework developers list

Re: [Springframework-developer] how to determine if a bean exists in registry?

[Rajeev K. <Ra...@cu...>]

Message Although, I would still prefer a simpler method that just =
returns a boolean, but your solution will work for me.

Thanks!!!!


----- Original Message -----=20
  From: Dmitriy Kopylenko=20
  To: spr...@li...=20
  Sent: Wednesday, November 19, 2003 11:15 AM
  Subject: RE: [Springframework-developer] how to determine if a bean =
exists in registry?


  Or better yet use AbstractBeanFactory.getBeanDefinition(String =
beanName) which would throw NoSuchBeanDefinitionException if bean does =
not exist.

  Regards,
  Dmitriy.
    -----Original Message-----
    From: spr...@li... =
[mailto:spr...@li...] On Behalf =
Of Kopylenko, Dmitry
    Sent: Wednesday, November 19, 2003 2:08 PM
    To: 'spr...@li...'
    Subject: RE: [Springframework-developer] how to determine if a bean =
exists in registry?


    Rajeev,

    you could use String[] getAliases(String name) throws =
NoSuchBeanDefinitionException in BeanFactory and catch =
NoSuchBeanDefinitionException. If caught, then bean does not exist in =
the factory.

    Dmitriy.
      -----Original Message-----
      From: Rajeev Kaul [mailto:Ra...@cu...]=20
      Sent: Wednesday, November 19, 2003 1:54 PM
      To: spr...@li...
      Subject: [Springframework-developer] how to determine if a bean =
exists in registry?


      Is there an easy way to determine if a certain bean exists in the =
beanFactory?  I know one can use the getBean(name) to determine that, =
but it seems an expensive call,  especially, if there are bean post =
processors associated with it.  Don't you think having a function like   =
 boolean containsBean(String beanName) in a beanFactory class would be =
useful here?

      Rajeev Kaul

RE: [Springframework-developer] how to determine if a bean exists in registry?

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

Or better yet use AbstractBeanFactory.getBeanDefinition(String beanName)
which would throw NoSuchBeanDefinitionException if bean does not exist.
=20
Regards,
Dmitriy.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Kopylenko, Dmitry
Sent: Wednesday, November 19, 2003 2:08 PM
To: 'spr...@li...'
Subject: RE: [Springframework-developer] how to determine if a bean =
exists
in registry?


Rajeev,
=20
you could use String[] getAliases(String name) throws
NoSuchBeanDefinitionException in BeanFactory and catch
NoSuchBeanDefinitionException. If caught, then bean does not exist in =
the
factory.
=20
Dmitriy.

-----Original Message-----
From: Rajeev Kaul [mailto:Ra...@cu...]=20
Sent: Wednesday, November 19, 2003 1:54 PM
To: spr...@li...
Subject: [Springframework-developer] how to determine if a bean exists =
in
registry?


Is there an easy way to determine if a certain bean exists in the
beanFactory?  I know one can use the getBean(name) to determine that, =
but it
seems an expensive call,  especially, if there are bean post processors
associated with it.  Don't you think having a function like    boolean
containsBean(String beanName) in a beanFactory class would be useful =
here?
=20
Rajeev Kaul

RE: [Springframework-developer] how to determine if a bean exists in registry?

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

Rajeev,
 
you could use String[] getAliases(String name) throws
NoSuchBeanDefinitionException in BeanFactory and catch
NoSuchBeanDefinitionException. If caught, then bean does not exist in the
factory.
 
Dmitriy.

-----Original Message-----
From: Rajeev Kaul [mailto:Ra...@cu...] 
Sent: Wednesday, November 19, 2003 1:54 PM
To: spr...@li...
Subject: [Springframework-developer] how to determine if a bean exists in
registry?


Is there an easy way to determine if a certain bean exists in the
beanFactory?  I know one can use the getBean(name) to determine that, but it
seems an expensive call,  especially, if there are bean post processors
associated with it.  Don't you think having a function like    boolean
containsBean(String beanName) in a beanFactory class would be useful here?
 
Rajeev Kaul

[Springframework-developer] how to determine if a bean exists in registry?

[Rajeev K. <Ra...@cu...>]

Is there an easy way to determine if a certain bean exists in the =
beanFactory?  I know one can use the getBean(name) to determine that, =
but it seems an expensive call,  especially, if there are bean post =
processors associated with it.  Don't you think having a function like   =
 boolean containsBean(String beanName) in a beanFactory class would be =
useful here?

Rajeev Kaul

[Springframework-developer] And we now have a page...

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

On the C2 wiki...

http://c2.com/cgi-bin/wiki?SpringFramework

Regards,
Rod

Re: [Springframework-developer] Why store configuration in a database?

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

Rob,

As Dmitriy pointed out, you might want to check out the JDBC bean factory.
It's pretty simplistic, and you're the first user who has asked about
storing config in the database, so you may want to enhance it and provide a
patch.

My experience has been that putting a small minority of config in the
database can make sense. But I've seldom seen good results from putting
_all_ config in the database; it gets so complex. So perhaps an ability to
_override_ XML definitions in the DB would make sense, as we have overriding
from properties.

I like your suggestions regarding a wider range of contexts. I think a
"cluster-wide" URL context is an obvious candidate. It shouldn't be too
difficult to open a web app up to this. Juergen, what do you think?

Regards,
Rod

----- Original Message ----- 
From: "Rob Butler" <rob...@ve...>
To: <spr...@li...>
Sent: Wednesday, November 19, 2003 1:54 AM
Subject: [Springframework-developer] Why store configuration in a database?


> Why would I want to store my configuration in a database?
>
> Simple - security, history, audit trail, centralized management.
>
> Security: With all the configuration data stored in a database it can have
> advanced security wrapped around it.  This would allow for tight control
> over which parameters can be changed and by who.  Thus providing a much
> finer grain of control than file based configurations can.  Operational
> staff can be allowed to change some parameters, while other parameters
> modifications are limited to developers only.
>
> History: All configuration changes can be logged in the database.  This
> could be used to allow rollbacks to configuration modifications if
something
> got changed that shouldn't have.
>
> Audit trail:  Who changed what when.  This can be critically important if
> all of a sudden your application has problems.  See who changed it, what
> they changed - you could even require comments so that a reason for the
> change can be noted.
>
> Centralized management:  Often an application will have many instances, on
> many nodes.  There may also be different environments for each stage of an
> application (Development, QA, Production).  If all environments are
managed
> from a central repository configuration migration can be simplified.  Once
> your app is moved out of QA, apply the appropriate configuration updates
to
> Production...  This is made very easy because all the configuration data
is
> already in the database.  Just migrate the appropriate portions.
>
> Wrap the database with some JDBC or Hibernate DAO's, and put some JMX
mbeans
> on top of that.  You now have a fully JMX enabled configuration system.
>
> Someone had previously mentioned that they didn't like having
configuration
> data stored in a database because if you had two machines using the same
> database for configuration, you would have to update both, or neither.
This
> is not necessarily true.
>
> Spring supports the concept of "contexts".  Why not extend this concept to
> encompase a larger realm.  In addition to the app global, and servlet
> specific contexts that Spring already supports we can add:
>
> /geographic location
> /cluster
> /node
> /application
> /instance
> /spring's existing app global
> /spring's existing servlet specific
>
> All the "contexts" above Spring's existing contexts are arbitrary.  Define
> as many as you want / need.  Now you can change the application
> configuration on one instance of an application, and then migrate those
> changes to the others as you need.  You can also continue to move the
> configuration changes up the context hierarchy or copy configuration
changes
> from one context to another.  No changes to Spring should be necessary for
> the addition of these higher level contexts.
>
> Whatever mechanism you decide to use for moving your configuration data
out
> of the database and into your application would "handle" the higher level
> "contexts".  For example, if you were using the JdbcBeanFactory you would
> write your SQL query so that it would obtain only the appropriate
> configuration data for it's "context".  So, if you had a context of
> /cluster1/node1/app3/instance2 you would have your JdbcBeanFactory specify
> that as part of it's SQL so only that data was retrieved (or other
> parameters which were higher up in the context, but not over-ridden in a
> lower context).
>
> Another option would be to use JMS to send updated config parameters to
your
> app.  A MDB or the like would listen for any message, and upon receiving
one
> update the appropriate files for your app.  It could then signal your app
to
> reload it's configuration data using the updated files.  This has the
added
> benefit of "caching" your configuration data.  I.E. if your configuration
DB
> is down, your app can still start up with the copy of the configuration
that
> is on it's HDD.
>
> If you didn't want to use a database, you could have JMX mbeans directly
> update the Spring config files, and then signal Spring to reload.  This
way
> your JMX config changes are saved so they will still be in effect the next
> time your app is started.
>
> Now all that is needed to make Spring fully dynamic is a way to "reload" a
> configuration while your app is running.  I've got a few thoughts on this
> too, but this e-mail is already long enough.
>
> Thoughts / comments?
>
> Later
> Rob
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] Why store configuration in a database?

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

Why would I want to store my configuration in a database?

Simple - security, history, audit trail, centralized management.

Security: With all the configuration data stored in a database it can have
advanced security wrapped around it.  This would allow for tight control
over which parameters can be changed and by who.  Thus providing a much
finer grain of control than file based configurations can.  Operational
staff can be allowed to change some parameters, while other parameters
modifications are limited to developers only.

History: All configuration changes can be logged in the database.  This
could be used to allow rollbacks to configuration modifications if something
got changed that shouldn't have.

Audit trail:  Who changed what when.  This can be critically important if
all of a sudden your application has problems.  See who changed it, what
they changed - you could even require comments so that a reason for the
change can be noted.

Centralized management:  Often an application will have many instances, on
many nodes.  There may also be different environments for each stage of an
application (Development, QA, Production).  If all environments are managed
from a central repository configuration migration can be simplified.  Once
your app is moved out of QA, apply the appropriate configuration updates to
Production...  This is made very easy because all the configuration data is
already in the database.  Just migrate the appropriate portions.

Wrap the database with some JDBC or Hibernate DAO's, and put some JMX mbeans
on top of that.  You now have a fully JMX enabled configuration system.

Someone had previously mentioned that they didn't like having configuration
data stored in a database because if you had two machines using the same
database for configuration, you would have to update both, or neither.  This
is not necessarily true.

Spring supports the concept of "contexts".  Why not extend this concept to
encompase a larger realm.  In addition to the app global, and servlet
specific contexts that Spring already supports we can add:

/geographic location
/cluster
/node
/application
/instance
/spring's existing app global
/spring's existing servlet specific

All the "contexts" above Spring's existing contexts are arbitrary.  Define
as many as you want / need.  Now you can change the application
configuration on one instance of an application, and then migrate those
changes to the others as you need.  You can also continue to move the
configuration changes up the context hierarchy or copy configuration changes
from one context to another.  No changes to Spring should be necessary for
the addition of these higher level contexts.

Whatever mechanism you decide to use for moving your configuration data out
of the database and into your application would "handle" the higher level
"contexts".  For example, if you were using the JdbcBeanFactory you would
write your SQL query so that it would obtain only the appropriate
configuration data for it's "context".  So, if you had a context of
/cluster1/node1/app3/instance2 you would have your JdbcBeanFactory specify
that as part of it's SQL so only that data was retrieved (or other
parameters which were higher up in the context, but not over-ridden in a
lower context).

Another option would be to use JMS to send updated config parameters to your
app.  A MDB or the like would listen for any message, and upon receiving one
update the appropriate files for your app.  It could then signal your app to
reload it's configuration data using the updated files.  This has the added
benefit of "caching" your configuration data.  I.E. if your configuration DB
is down, your app can still start up with the copy of the configuration that
is on it's HDD.

If you didn't want to use a database, you could have JMX mbeans directly
update the Spring config files, and then signal Spring to reload.  This way
your JMX config changes are saved so they will still be in effect the next
time your app is started.

Now all that is needed to make Spring fully dynamic is a way to "reload" a
configuration while your app is running.  I've got a few thoughts on this
too, but this e-mail is already long enough.

Thoughts / comments?

Later
Rob

Re: [Springframework-developer] no ListableWebApplicationContext?

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

Dmitriy,

Yes I saw that, and i saw the ListableBeanFactory too.  But these are not
supported in the WebApplicationContext.  It doesn't appear as if you can
swap the bean factory used by the available ApplicationContexts (In spring
M2 anyways)

(ContextLoaderServlet or ContextLoaderListener) calls ContextLoader init....

ContextLoader init allows for the WebApplicationContext to be changed by
passing a parameter from web.xml - this is good.

However, there are only StaticWebApplicationContext (which should be used
for testing only - not in production as stated in the javadoc) and the
FileSystemXmlApplicationContext, ClassPathXmlApplicationContext, and
XmlWebApplicationContext all of which inherit from
AbstractXmlApplicationContext.

AbstractXmlApplicationContext only uses a XmlBeanFactory and cannot be
changed to use a different one.  Thus, there is no WebApplicationContext
that ContextLoader can use which supports ListableBeanFactory, or
JdbcBeanFactory provided in Spring.

Later
Rob
----- Original Message -----
From: "Kopylenko, Dmitry" <dko...@ac...>
To: "'Rob Butler '" <rob...@ve...>;
<spr...@li...>
Sent: Tuesday, November 18, 2003 8:00 PM
Subject: RE: [Springframework-developer] no ListableWebApplicationContext?


> Rob,
>
> there is a JdbcBeanFactory implementation already available. Check it out:
>
http://www.springframework.org/docs/api/org/springframework/jdbc/core/suppor
> t/JdbcBeanFactory.html
>
> Regards,
> Dmitriy.
>
> -----Original Message-----
> From: Rob Butler
> To: spr...@li...
> Sent: 11/18/2003 7:43 PM
> Subject: [Springframework-developer] no ListableWebApplicationContext?
>
> Hello all,
>
> I was looking over the Spring code and it doesn't appear as if there is
> support for a ListableWebApplicationContext.  i.e. a
> WebApplicationContext
> that uses property files instead of XML.  Shouldn't this be added to the
> framework?
>
> The ContextLoader already supports using a parameter to select a
> different
> WebApplicationContext implementation, so adding
> ListableWebApplicationContext support shouldn't be too difficult.  It
> would
> be nice if the ContextLoader were modified to try the
> XmlWebApplicationContext first, and if that is not found to try the
> ListableWebApplicationContext.  In that way if either of the two Spring
> provided WebApplicationContexts were used they would be found
> automatically.
>
> I would like ListableWebApplicationContext support because I plan on
> holding
> my configuration data in a database and then have the database generate
> the
> property files.  It's easier to have the database write out property
> files
> than XML.  At the moment I don't want the properties obtained directly
> from
> the database.  But, now that I mention it, JdbcWebApplicationContext
> support
> should be added to the framework too, just to be complete.
>
> Why would I want to do any of this?  Ah, that is the subject of a future
> e-mail...  More to come.
>
> Later
> Rob
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] Re: no ListableWebApplicationContext?

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

Rob

I think you'll find Listable properties are available using:

http://www.springframework.org/docs/api/org/springframework/web/context/supp
ort/StaticWebApplicationContext.html

Roger


"Rob Butler" <rob...@ve...> wrote in message
news:002201c3ae36$316e11f0$0802a8c0@coderhp...
> Hello all,
>
> I was looking over the Spring code and it doesn't appear as if there is
> support for a ListableWebApplicationContext.  i.e. a WebApplicationContext
> that uses property files instead of XML.  Shouldn't this be added to the
> framework?
>
> The ContextLoader already supports using a parameter to select a different
> WebApplicationContext implementation, so adding
> ListableWebApplicationContext support shouldn't be too difficult.  It
would
> be nice if the ContextLoader were modified to try the
> XmlWebApplicationContext first, and if that is not found to try the
> ListableWebApplicationContext.  In that way if either of the two Spring
> provided WebApplicationContexts were used they would be found
automatically.
>
> I would like ListableWebApplicationContext support because I plan on
holding
> my configuration data in a database and then have the database generate
the
> property files.  It's easier to have the database write out property files
> than XML.  At the moment I don't want the properties obtained directly
from
> the database.  But, now that I mention it, JdbcWebApplicationContext
support
> should be added to the framework too, just to be complete.
>
> Why would I want to do any of this?  Ah, that is the subject of a future
> e-mail...  More to come.
>
> Later
> Rob
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/

RE: [Springframework-developer] no ListableWebApplicationContext?

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

Rob,

there is a JdbcBeanFactory implementation already available. Check it out:
http://www.springframework.org/docs/api/org/springframework/jdbc/core/suppor
t/JdbcBeanFactory.html 

Regards,
Dmitriy.

-----Original Message-----
From: Rob Butler
To: spr...@li...
Sent: 11/18/2003 7:43 PM
Subject: [Springframework-developer] no ListableWebApplicationContext?

Hello all,

I was looking over the Spring code and it doesn't appear as if there is
support for a ListableWebApplicationContext.  i.e. a
WebApplicationContext
that uses property files instead of XML.  Shouldn't this be added to the
framework?

The ContextLoader already supports using a parameter to select a
different
WebApplicationContext implementation, so adding
ListableWebApplicationContext support shouldn't be too difficult.  It
would
be nice if the ContextLoader were modified to try the
XmlWebApplicationContext first, and if that is not found to try the
ListableWebApplicationContext.  In that way if either of the two Spring
provided WebApplicationContexts were used they would be found
automatically.

I would like ListableWebApplicationContext support because I plan on
holding
my configuration data in a database and then have the database generate
the
property files.  It's easier to have the database write out property
files
than XML.  At the moment I don't want the properties obtained directly
from
the database.  But, now that I mention it, JdbcWebApplicationContext
support
should be added to the framework too, just to be complete.

Why would I want to do any of this?  Ah, that is the subject of a future
e-mail...  More to come.

Later
Rob



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] no ListableWebApplicationContext?

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

Hello all,

I was looking over the Spring code and it doesn't appear as if there is
support for a ListableWebApplicationContext.  i.e. a WebApplicationContext
that uses property files instead of XML.  Shouldn't this be added to the
framework?

The ContextLoader already supports using a parameter to select a different
WebApplicationContext implementation, so adding
ListableWebApplicationContext support shouldn't be too difficult.  It would
be nice if the ContextLoader were modified to try the
XmlWebApplicationContext first, and if that is not found to try the
ListableWebApplicationContext.  In that way if either of the two Spring
provided WebApplicationContexts were used they would be found automatically.

I would like ListableWebApplicationContext support because I plan on holding
my configuration data in a database and then have the database generate the
property files.  It's easier to have the database write out property files
than XML.  At the moment I don't want the properties obtained directly from
the database.  But, now that I mention it, JdbcWebApplicationContext support
should be added to the framework too, just to be complete.

Why would I want to do any of this?  Ah, that is the subject of a future
e-mail...  More to come.

Later
Rob

[Springframework-developer] AutoProxyCreator problem

[Rajeev K. <Ra...@cu...>]

I have been trying to use BeanNameAutoProxyCreator class (I noticed =
there are no test cases for it) to create proxies for "prototype" =
business objects. I extended the BeanNameAutoProxyCreator class to use =
the PrototypeInvokerInterceptor in the "createInvokerInterceptor()" =
method.  However, this results in an infinite loop, as the =
PrototypeInvokerInterceptor calls the beanFactory getBean() method which =
in turn triggers the beanPostProcessor and the cycle repeats endlessly.

Any suggestions on getting around this problem?

It would have been better, if the BeanNameAutoProxyCreator class was =
designed to take invokerInterceptor as a property, which could be =
specified in the configuration, instead of having to subclass it to use =
other invokerInterceptor(s).=20

Rajeev Kaul

[Springframework-developer] RedirectView

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

Everyone,

In org.springframework.web.servlet.view.RedirectView

Line 71: url.append(URLEncoder.encode(entry.getKey().toString());
Line 73: url.append(URLEncoder.encode(entry.getValue().toString()));

URLEncoder.encode(String) is deprecated. Does anyone mind if I change it to
url.append(URLEncoder.encode(entry.getKey().toString(), "UTF-8"))
 and url.append(URLEncoder.encode(entry.getValue().toString(), "UTF-8"))
respectively ?

Regards,
Dmitriy.

Re: [Springframework-developer] A new TSS article, by Bruce Tate :-)

[<tri...@tr...>]

Jürgen & Rod,

This is fantastic.  To have "Mr. Bitter Java/EJB" endorse your lightweight Java
framework is going to attract a lot of interest.  I have noticed a lot more
messages on the mailing list lately, it might quadrupel the next few weeks.

Congratulations on some well deserved recognition.

Thomas

Quoting "jürgen höller [werk3AT]" <jue...@we...>:

> Bruce Tate is indeed a Spring fan, not only does he promote Spring at the "No
> Fluff, Just Stuff" conference series but also...
> http://www.theserverside.com/home/thread.jsp?thread_id=22481
> 
> The essence? Spring and Hibernate are a viable way to battle J2EE complexity.
> It makes me rejoice to see this message getting spread by someone who isn't
> affiliated with the projects at all!
> 
> Juergen
> 
> 
> DI Jürgen Höller
> Senior System Architect
> ______________________________________
> 
> werk3ATS - division systementwicklung
> werk3AT informations- und mediensysteme
> 
> europaplatz 4
> A - 4020 linz
> 
> t.  +43 (0) 732 71 65 29 502
> f.  +43 (0) 732 71 65 29 3
> mailto:jue...@we...
> http://www.werk3at.com
> ______________________________________
> werk3ATS - WIR ENTWICKELN ERFOLG
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] Re: Creating Application Context getBean 'closures'

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

Chris Nokleberg wrote:

>Colin Sampaleanu wrote:
>  
>
>>I think I may be missing something, but I think it's desireable to be
>>able to create in an easy fashion, 'closures' which encapsulate getting
>>a bean from a bean factory.
>>
>>Say you have an interface
>>  interface MyInteface {   ... whatever }
>>
>>and you have a factory Interface
>>  interface MyInterfaceFactory {
>>    MyInterface getInstance();
>>  }
>>    
>>
>
>You may want to look at:
>http://cglib.sourceforge.net/apidocs/net/sf/cglib/reflect/MethodDelegate.html
>
>It can create an object that implements an interface but delegates the
>implementation to a virtual or static method (with matching signature) of
>your choice. Essentially it is a implementation of C# delegates for Java.
>  
>
Thanks Chris. I don't think though this provides any fundamental 
advantage over just using AdvisedSupport in Spring as used by 
ProxyFactoryBean. The fact that it only delegates to a method with a 
matching signature is a problem too (unless I'm missing something). The 
code would have to delegate to a method with an Object return value, 
with the proxy doing something like a ClassCastException if the return 
value (at runtime) didn't match.

[Springframework-developer] A new TSS article, by Bruce Tate :-)

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

Bruce Tate is indeed a Spring fan, not only does he promote Spring at =
the "No Fluff, Just Stuff" conference series but also...
http://www.theserverside.com/home/thread.jsp?thread_id=3D22481

The essence? Spring and Hibernate are a viable way to battle J2EE =
complexity. It makes me rejoice to see this message getting spread by =
someone who isn't affiliated with the projects at all!

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

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

[Springframework-developer] Re: Creating Application Context getBean 'closures'

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

Colin Sampaleanu wrote:

> I think I may be missing something, but I think it's desireable to be
> able to create in an easy fashion, 'closures' which encapsulate getting
> a bean from a bean factory.
> 
> Say you have an interface
>   interface MyInteface {   ... whatever }
> 
> and you have a factory Interface
>   interface MyInterfaceFactory {
>     MyInterface getInstance();
>   }

You may want to look at:
http://cglib.sourceforge.net/apidocs/net/sf/cglib/reflect/MethodDelegate.html

It can create an object that implements an interface but delegates the
implementation to a virtual or static method (with matching signature) of
your choice. Essentially it is a implementation of C# delegates for Java.

Chris

[Springframework-developer] Creating Application Context getBean 'closures'

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

I think I may be missing something, but I think it's desireable to be 
able to create in an easy fashion, 'closures' which encapsulate getting 
a bean from a bean factory.

Say you have an interface
  interface MyInteface {   ... whatever }

and you have a factory Interface
  interface MyInterfaceFactory {
    MyInterface getInstance();
  }

And you have a user of the factory, who you'd rather have no knowledge 
of Spring, which is why he's using the factory instead of calling 
getBean himself:
class User {
  MyInterfaceFactory _myfac;
  public void setMyInterfaceFactory(MyInterfaceFactory myfac) { _myfac = 
myfac; }
  public void someMethod() {
    // need a new instance of MyInterface to work with
    MyInterface myint = _myfac.getInstance();
      ...
  }
}

Now I have a bean factory
<beans>
  <bean id="myinterface" singleton="false" 
class="com.whatever.MyInterfaceImpl">
  </bean>
  <bean id="user" class="com.whatever.User">
    <property name="myInterfaceFactory"><ref bean="xxxxxxxx"/></property>
  </bean>
</beans>

now, as per the above, context.getBean("myinterface") is already a 
factory for objects implementing MyInterface. But I don't want the User 
object to know anything about contexts. And I'd rather not create an 
actual object that implements MyInterfaceFactory. It seems like a waste, 
since all I am doing here is trying to create a level of indirection, 
and I already have a factory inside the context itself, and I may want 
to use this approach in 30 different places, just to add a level of 
indirection in creating new objects.

So what I think is needed is some variation of ProxyFactoryBean (but a 
separate class), which given a target bean (which is itself a factory), 
and a factory interface having a method with no args which returns a 
certain type, creates on the fly a new class implementing the factory 
interface, which will just use the target factory bean to actually 
supply the instance. So the bean def above would become:
<beans>
  <bean id="myinterface" singleton="false" 
class="com.whatever.MyInterfaceImpl">
  </bean>
  <bean id="myinterface-factory" class="org.springframework.whatever.XXXX">
    <property name="targetBean"><ref bean="xxxxxxxx"/></property>
    <property 
name="interface"><value>x.y.z.AFactoryInterface</value></property>
  </bean>
  <bean id="user" class="com.whatever.User">
    <property name="myInterfaceFactory"><ref 
bean="myinterface-factory"/></property>
  </bean>
</beans>

Am I missing an existing way to do this? Is this worth adding to spring 
as a convenience built-in, along the lines of TransactionProxyFactoryBean?

RE: [Springframework-developer] Re: Eclipse problem when running entire test suite

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

Line 125 in method "testInterceptorInclusionMethods" fails, in both Ant =
and IDEA:

  assertTrue(factory.countInterceptorsOfType(InvokerInterceptor.class) =
=3D=3D 1);

Admittedly, this isn't really related to Eclipse, thus the "BTW" :-)

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Tuesday, November 18, 2003 4:11 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: Eclipse problem when
running entire test suite


Command-line, or in Eclipse?  It doesn't fail for me in either. The only =

tests which fail for me right now, in both environments, are=20
CompilerTests and AttributeWriterTests.



j=FCrgen h=F6ller [werk3AT] wrote:

>BTW, I just updated from CVS, and ProxyFactoryTests fails now...
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Rod Johnson
>Sent: Tuesday, November 18, 2003 3:48 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Re: Eclipse problem when
>running entire test suite
>
>
>Colin,
>
>Thanks very much for tracking this problem down and fixing it.
>
>I've fixed the single test that was failing, which relied on a static =
that
>was not reset before that test. So now all tests pass in Eclipse again, =
and
>I can run the whole test suite in 30 seconds vs 3 minutes from Ant. =
Trivial
>to run _all_ tests instead of just a few before any commit.
>
>Regards,
>Rod
>
>----- Original Message -----=20
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Tuesday, November 18, 2003 3:38 AM
>Subject: [Springframework-developer] Re: Eclipse problem when running =
entire
>test suite
>
>
> =20
>
>>There was only one test actually calling System.setProperties, and
>>wiping out the System properties. I made that test restore them
>>afterwards, and now when running the entire suite in Eclipse all the
>>Errors are gone. So at this point there is only one test which fails =
in
>>Eclipse and not via command-line, and only when running the entire =
test
>>suite. That's
>>  ListableBeanFactoryImplTestSuite
>>I presume that for this as well there is interference from another =
test,
>>but I don't have time to look at it.
>>
>>
>>
>>Colin Sampaleanu wrote:
>>
>>   =20
>>
>>>I had a few minutes now to take a look at this. I figured out what is
>>>hosing the NestedCheckedExceptionTests (possibly the others too, but =
I
>>>just looked at the first one).
>>>
>>>When run as part of the test suite, it dies with a
>>>NullPointerException on this line:
>>>            nce.printStackTrace(pw);
>>>and it dies because it eventually gets and tries to use the System
>>>property 'line.separator'. The problem is that one of the other tests
>>>has killed all the normal system properties.
>>>
>>>Looks like Eclipse runs all tests in the same 'run' in the same vm =
(as
>>>opposed to our ant build script, which calls 'batchtest' with
>>>fork=3D"yes").
>>>
>>>Now one solution would be to make sure all tests restore system
>>>properties after overriding them. Alternately, does anybody know how
>>>to force Eclipse to use a new vm for each test in a testsuite? I am
>>>using 3.0M4, and there doesn't seem to be any option for this.
>>>
>>>
>>>Colin Sampaleanu wrote:
>>>
>>>     =20
>>>
>>>>If I do a 'rebuild all', then run all tests, I get the following
>>>>failures:
>>>>Fails:
>>>>
>>>>       =20
>>>>
>testFactoryBeanDidNotCreatePrototype(org.springframework.beans.factory.L=
ista
>bleBeanFactoryImplTestSuite)
> =20
>
>>>>testAttributes(org.springframework.metadata.bcel.AttributeWriterTests=
)
>>>>
>>>>       =20
>>>>
>testAbbreviatedAttribute(org.springframework.metadata.bcel.AttributeWrit=
erTe
>sts)
> =20
>
>>>>testMethods(org.springframework.metadata.bcel.AttributeWriterTests)
>>>>testFields(org.springframework.metadata.bcel.AttributeWriterTests)
>>>>testSingleFile(org.springframework.metadata.qdox.CompilerTests)
>>>>Errors:
>>>>
>>>>       =20
>>>>
>testWithApplicationContext(org.springframework.web.multipart.commons.Com=
mons
>MultipartResolverTests)
> =20
>
>>>>       =20
>>>>
>testWithServletContextAndFilter(org.springframework.web.multipart.common=
s.Co
>mmonsMultipartResolverTests)
> =20
>
>>>>       =20
>>>>
>testWithServletContextAndFilterWithCustomBeanName(org.springframework.we=
b.mu
>ltipart.commons.CommonsMultipartResolverTests)
> =20
>
>>>>testNoRootCause(org.springframework.core.NestedCheckedExceptionTests)=

>>>>testRootCause(org.springframework.core.NestedCheckedExceptionTests)
>>>>
>>>>Now AttributeWriterTests and CompilerTests fail from command-line =
ant
>>>>already. The other 3 test cases (6 tests total) all execute ok if =
run
>>>>individually, but fail if run as part of running the whole suite.
>>>>Very weird. What is also annoying is that on the errors, Eclipse
>>>>doesn't actually give any details as to what the problem is when
>>>>running multiple tests. Rod, I don't even know how you figured out
>>>>it's a NoClassDefFoundError. The only time I've ever been able to
>>>>print out an error in that case was when running one test case
>>>>individually, but in this case they all work fine individually.
>>>>
>>>>
>>>>
>>>>Rod Johnson wrote:
>>>>
>>>>       =20
>>>>
>>>>>It seems to be a NoClassDefFoundError, and it affects mainly the
>>>>>Hibernate
>>>>>call to config.buildSessionFactory() and anything to do with CGLIB.
>>>>>
>>>>>I don't have time to dig deeper right now, but does anyone have any
>>>>>tips?
>>>>>
>>>>>Regards,
>>>>>Rod
>>>>>         =20
>>>>>




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

Re: [Springframework-developer] Re: Eclipse problem when running entire test suite

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

Command-line, or in Eclipse?  It doesn't fail for me in either. The only 
tests which fail for me right now, in both environments, are 
CompilerTests and AttributeWriterTests.



jürgen höller [werk3AT] wrote:

>BTW, I just updated from CVS, and ProxyFactoryTests fails now...
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Rod Johnson
>Sent: Tuesday, November 18, 2003 3:48 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Re: Eclipse problem when
>running entire test suite
>
>
>Colin,
>
>Thanks very much for tracking this problem down and fixing it.
>
>I've fixed the single test that was failing, which relied on a static that
>was not reset before that test. So now all tests pass in Eclipse again, and
>I can run the whole test suite in 30 seconds vs 3 minutes from Ant. Trivial
>to run _all_ tests instead of just a few before any commit.
>
>Regards,
>Rod
>
>----- Original Message ----- 
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Tuesday, November 18, 2003 3:38 AM
>Subject: [Springframework-developer] Re: Eclipse problem when running entire
>test suite
>
>
>  
>
>>There was only one test actually calling System.setProperties, and
>>wiping out the System properties. I made that test restore them
>>afterwards, and now when running the entire suite in Eclipse all the
>>Errors are gone. So at this point there is only one test which fails in
>>Eclipse and not via command-line, and only when running the entire test
>>suite. That's
>>  ListableBeanFactoryImplTestSuite
>>I presume that for this as well there is interference from another test,
>>but I don't have time to look at it.
>>
>>
>>
>>Colin Sampaleanu wrote:
>>
>>    
>>
>>>I had a few minutes now to take a look at this. I figured out what is
>>>hosing the NestedCheckedExceptionTests (possibly the others too, but I
>>>just looked at the first one).
>>>
>>>When run as part of the test suite, it dies with a
>>>NullPointerException on this line:
>>>            nce.printStackTrace(pw);
>>>and it dies because it eventually gets and tries to use the System
>>>property 'line.separator'. The problem is that one of the other tests
>>>has killed all the normal system properties.
>>>
>>>Looks like Eclipse runs all tests in the same 'run' in the same vm (as
>>>opposed to our ant build script, which calls 'batchtest' with
>>>fork="yes").
>>>
>>>Now one solution would be to make sure all tests restore system
>>>properties after overriding them. Alternately, does anybody know how
>>>to force Eclipse to use a new vm for each test in a testsuite? I am
>>>using 3.0M4, and there doesn't seem to be any option for this.
>>>
>>>
>>>Colin Sampaleanu wrote:
>>>
>>>      
>>>
>>>>If I do a 'rebuild all', then run all tests, I get the following
>>>>failures:
>>>>Fails:
>>>>
>>>>        
>>>>
>testFactoryBeanDidNotCreatePrototype(org.springframework.beans.factory.Lista
>bleBeanFactoryImplTestSuite)
>  
>
>>>>testAttributes(org.springframework.metadata.bcel.AttributeWriterTests)
>>>>
>>>>        
>>>>
>testAbbreviatedAttribute(org.springframework.metadata.bcel.AttributeWriterTe
>sts)
>  
>
>>>>testMethods(org.springframework.metadata.bcel.AttributeWriterTests)
>>>>testFields(org.springframework.metadata.bcel.AttributeWriterTests)
>>>>testSingleFile(org.springframework.metadata.qdox.CompilerTests)
>>>>Errors:
>>>>
>>>>        
>>>>
>testWithApplicationContext(org.springframework.web.multipart.commons.Commons
>MultipartResolverTests)
>  
>
>>>>        
>>>>
>testWithServletContextAndFilter(org.springframework.web.multipart.commons.Co
>mmonsMultipartResolverTests)
>  
>
>>>>        
>>>>
>testWithServletContextAndFilterWithCustomBeanName(org.springframework.web.mu
>ltipart.commons.CommonsMultipartResolverTests)
>  
>
>>>>testNoRootCause(org.springframework.core.NestedCheckedExceptionTests)
>>>>testRootCause(org.springframework.core.NestedCheckedExceptionTests)
>>>>
>>>>Now AttributeWriterTests and CompilerTests fail from command-line ant
>>>>already. The other 3 test cases (6 tests total) all execute ok if run
>>>>individually, but fail if run as part of running the whole suite.
>>>>Very weird. What is also annoying is that on the errors, Eclipse
>>>>doesn't actually give any details as to what the problem is when
>>>>running multiple tests. Rod, I don't even know how you figured out
>>>>it's a NoClassDefFoundError. The only time I've ever been able to
>>>>print out an error in that case was when running one test case
>>>>individually, but in this case they all work fine individually.
>>>>
>>>>
>>>>
>>>>Rod Johnson wrote:
>>>>
>>>>        
>>>>
>>>>>It seems to be a NoClassDefFoundError, and it affects mainly the
>>>>>Hibernate
>>>>>call to config.buildSessionFactory() and anything to do with CGLIB.
>>>>>
>>>>>I don't have time to dig deeper right now, but does anyone have any
>>>>>tips?
>>>>>
>>>>>Regards,
>>>>>Rod
>>>>>          
>>>>>

RE: [Springframework-developer] Re: Eclipse problem when running entire test suite

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

BTW, I just updated from CVS, and ProxyFactoryTests fails now...


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Tuesday, November 18, 2003 3:48 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: Eclipse problem when
running entire test suite


Colin,

Thanks very much for tracking this problem down and fixing it.

I've fixed the single test that was failing, which relied on a static =
that
was not reset before that test. So now all tests pass in Eclipse again, =
and
I can run the whole test suite in 30 seconds vs 3 minutes from Ant. =
Trivial
to run _all_ tests instead of just a few before any commit.

Regards,
Rod

----- Original Message -----=20
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Tuesday, November 18, 2003 3:38 AM
Subject: [Springframework-developer] Re: Eclipse problem when running =
entire
test suite


> There was only one test actually calling System.setProperties, and
> wiping out the System properties. I made that test restore them
> afterwards, and now when running the entire suite in Eclipse all the
> Errors are gone. So at this point there is only one test which fails =
in
> Eclipse and not via command-line, and only when running the entire =
test
> suite. That's
>   ListableBeanFactoryImplTestSuite
> I presume that for this as well there is interference from another =
test,
> but I don't have time to look at it.
>
>
>
> Colin Sampaleanu wrote:
>
> > I had a few minutes now to take a look at this. I figured out what =
is
> > hosing the NestedCheckedExceptionTests (possibly the others too, but =
I
> > just looked at the first one).
> >
> > When run as part of the test suite, it dies with a
> > NullPointerException on this line:
> >             nce.printStackTrace(pw);
> > and it dies because it eventually gets and tries to use the System
> > property 'line.separator'. The problem is that one of the other =
tests
> > has killed all the normal system properties.
> >
> > Looks like Eclipse runs all tests in the same 'run' in the same vm =
(as
> > opposed to our ant build script, which calls 'batchtest' with
> > fork=3D"yes").
> >
> > Now one solution would be to make sure all tests restore system
> > properties after overriding them. Alternately, does anybody know how
> > to force Eclipse to use a new vm for each test in a testsuite? I am
> > using 3.0M4, and there doesn't seem to be any option for this.
> >
> >
> > Colin Sampaleanu wrote:
> >
> >> If I do a 'rebuild all', then run all tests, I get the following
> >> failures:
> >> Fails:
> >>
testFactoryBeanDidNotCreatePrototype(org.springframework.beans.factory.Li=
sta
bleBeanFactoryImplTestSuite)
> >>
> >> =
testAttributes(org.springframework.metadata.bcel.AttributeWriterTests)
> >>
testAbbreviatedAttribute(org.springframework.metadata.bcel.AttributeWrite=
rTe
sts)
> >>
> >> testMethods(org.springframework.metadata.bcel.AttributeWriterTests)
> >> testFields(org.springframework.metadata.bcel.AttributeWriterTests)
> >> testSingleFile(org.springframework.metadata.qdox.CompilerTests)
> >> Errors:
> >>
testWithApplicationContext(org.springframework.web.multipart.commons.Comm=
ons
MultipartResolverTests)
> >>
> >>
testWithServletContextAndFilter(org.springframework.web.multipart.commons=
.Co
mmonsMultipartResolverTests)
> >>
> >>
testWithServletContextAndFilterWithCustomBeanName(org.springframework.web=
.mu
ltipart.commons.CommonsMultipartResolverTests)
> >>
> >> =
testNoRootCause(org.springframework.core.NestedCheckedExceptionTests)
> >> testRootCause(org.springframework.core.NestedCheckedExceptionTests)
> >>
> >> Now AttributeWriterTests and CompilerTests fail from command-line =
ant
> >> already. The other 3 test cases (6 tests total) all execute ok if =
run
> >> individually, but fail if run as part of running the whole suite.
> >> Very weird. What is also annoying is that on the errors, Eclipse
> >> doesn't actually give any details as to what the problem is when
> >> running multiple tests. Rod, I don't even know how you figured out
> >> it's a NoClassDefFoundError. The only time I've ever been able to
> >> print out an error in that case was when running one test case
> >> individually, but in this case they all work fine individually.
> >>
> >>
> >>
> >> Rod Johnson wrote:
> >>
> >>> It seems to be a NoClassDefFoundError, and it affects mainly the
> >>> Hibernate
> >>> call to config.buildSessionFactory() and anything to do with =
CGLIB.
> >>>
> >>> I don't have time to dig deeper right now, but does anyone have =
any
> >>> tips?
> >>>
> >>> Regards,
> >>> Rod
> >>
>
>
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> =
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=3Dmm/g22lp.tmp=
l
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>




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

Re: [Springframework-developer] Re: Eclipse problem when running entire test suite

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

Colin,

Thanks very much for tracking this problem down and fixing it.

I've fixed the single test that was failing, which relied on a static that
was not reset before that test. So now all tests pass in Eclipse again, and
I can run the whole test suite in 30 seconds vs 3 minutes from Ant. Trivial
to run _all_ tests instead of just a few before any commit.

Regards,
Rod

----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Tuesday, November 18, 2003 3:38 AM
Subject: [Springframework-developer] Re: Eclipse problem when running entire
test suite


> There was only one test actually calling System.setProperties, and
> wiping out the System properties. I made that test restore them
> afterwards, and now when running the entire suite in Eclipse all the
> Errors are gone. So at this point there is only one test which fails in
> Eclipse and not via command-line, and only when running the entire test
> suite. That's
>   ListableBeanFactoryImplTestSuite
> I presume that for this as well there is interference from another test,
> but I don't have time to look at it.
>
>
>
> Colin Sampaleanu wrote:
>
> > I had a few minutes now to take a look at this. I figured out what is
> > hosing the NestedCheckedExceptionTests (possibly the others too, but I
> > just looked at the first one).
> >
> > When run as part of the test suite, it dies with a
> > NullPointerException on this line:
> >             nce.printStackTrace(pw);
> > and it dies because it eventually gets and tries to use the System
> > property 'line.separator'. The problem is that one of the other tests
> > has killed all the normal system properties.
> >
> > Looks like Eclipse runs all tests in the same 'run' in the same vm (as
> > opposed to our ant build script, which calls 'batchtest' with
> > fork="yes").
> >
> > Now one solution would be to make sure all tests restore system
> > properties after overriding them. Alternately, does anybody know how
> > to force Eclipse to use a new vm for each test in a testsuite? I am
> > using 3.0M4, and there doesn't seem to be any option for this.
> >
> >
> > Colin Sampaleanu wrote:
> >
> >> If I do a 'rebuild all', then run all tests, I get the following
> >> failures:
> >> Fails:
> >>
testFactoryBeanDidNotCreatePrototype(org.springframework.beans.factory.Lista
bleBeanFactoryImplTestSuite)
> >>
> >> testAttributes(org.springframework.metadata.bcel.AttributeWriterTests)
> >>
testAbbreviatedAttribute(org.springframework.metadata.bcel.AttributeWriterTe
sts)
> >>
> >> testMethods(org.springframework.metadata.bcel.AttributeWriterTests)
> >> testFields(org.springframework.metadata.bcel.AttributeWriterTests)
> >> testSingleFile(org.springframework.metadata.qdox.CompilerTests)
> >> Errors:
> >>
testWithApplicationContext(org.springframework.web.multipart.commons.Commons
MultipartResolverTests)
> >>
> >>
testWithServletContextAndFilter(org.springframework.web.multipart.commons.Co
mmonsMultipartResolverTests)
> >>
> >>
testWithServletContextAndFilterWithCustomBeanName(org.springframework.web.mu
ltipart.commons.CommonsMultipartResolverTests)
> >>
> >> testNoRootCause(org.springframework.core.NestedCheckedExceptionTests)
> >> testRootCause(org.springframework.core.NestedCheckedExceptionTests)
> >>
> >> Now AttributeWriterTests and CompilerTests fail from command-line ant
> >> already. The other 3 test cases (6 tests total) all execute ok if run
> >> individually, but fail if run as part of running the whole suite.
> >> Very weird. What is also annoying is that on the errors, Eclipse
> >> doesn't actually give any details as to what the problem is when
> >> running multiple tests. Rod, I don't even know how you figured out
> >> it's a NoClassDefFoundError. The only time I've ever been able to
> >> print out an error in that case was when running one test case
> >> individually, but in this case they all work fine individually.
> >>
> >>
> >>
> >> Rod Johnson wrote:
> >>
> >>> It seems to be a NoClassDefFoundError, and it affects mainly the
> >>> Hibernate
> >>> call to config.buildSessionFactory() and anything to do with CGLIB.
> >>>
> >>> I don't have time to dig deeper right now, but does anyone have any
> >>> tips?
> >>>
> >>> Regards,
> >>> Rod
> >>
>
>
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] Re: Eclipse problem when running entire test suite

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

There was only one test actually calling System.setProperties, and 
wiping out the System properties. I made that test restore them 
afterwards, and now when running the entire suite in Eclipse all the 
Errors are gone. So at this point there is only one test which fails in 
Eclipse and not via command-line, and only when running the entire test 
suite. That's
  ListableBeanFactoryImplTestSuite
I presume that for this as well there is interference from another test, 
but I don't have time to look at it.



Colin Sampaleanu wrote:

> I had a few minutes now to take a look at this. I figured out what is 
> hosing the NestedCheckedExceptionTests (possibly the others too, but I 
> just looked at the first one).
>
> When run as part of the test suite, it dies with a 
> NullPointerException on this line:
>             nce.printStackTrace(pw);
> and it dies because it eventually gets and tries to use the System 
> property 'line.separator'. The problem is that one of the other tests 
> has killed all the normal system properties.
>
> Looks like Eclipse runs all tests in the same 'run' in the same vm (as 
> opposed to our ant build script, which calls 'batchtest' with 
> fork="yes").
>
> Now one solution would be to make sure all tests restore system 
> properties after overriding them. Alternately, does anybody know how 
> to force Eclipse to use a new vm for each test in a testsuite? I am 
> using 3.0M4, and there doesn't seem to be any option for this.
>
>
> Colin Sampaleanu wrote:
>
>> If I do a 'rebuild all', then run all tests, I get the following 
>> failures:
>> Fails:
>> testFactoryBeanDidNotCreatePrototype(org.springframework.beans.factory.ListableBeanFactoryImplTestSuite) 
>>
>> testAttributes(org.springframework.metadata.bcel.AttributeWriterTests)
>> testAbbreviatedAttribute(org.springframework.metadata.bcel.AttributeWriterTests) 
>>
>> testMethods(org.springframework.metadata.bcel.AttributeWriterTests)
>> testFields(org.springframework.metadata.bcel.AttributeWriterTests)
>> testSingleFile(org.springframework.metadata.qdox.CompilerTests)
>> Errors:
>> testWithApplicationContext(org.springframework.web.multipart.commons.CommonsMultipartResolverTests) 
>>
>> testWithServletContextAndFilter(org.springframework.web.multipart.commons.CommonsMultipartResolverTests) 
>>
>> testWithServletContextAndFilterWithCustomBeanName(org.springframework.web.multipart.commons.CommonsMultipartResolverTests) 
>>
>> testNoRootCause(org.springframework.core.NestedCheckedExceptionTests)
>> testRootCause(org.springframework.core.NestedCheckedExceptionTests)
>>
>> Now AttributeWriterTests and CompilerTests fail from command-line ant 
>> already. The other 3 test cases (6 tests total) all execute ok if run 
>> individually, but fail if run as part of running the whole suite. 
>> Very weird. What is also annoying is that on the errors, Eclipse 
>> doesn't actually give any details as to what the problem is when 
>> running multiple tests. Rod, I don't even know how you figured out 
>> it's a NoClassDefFoundError. The only time I've ever been able to 
>> print out an error in that case was when running one test case 
>> individually, but in this case they all work fine individually.
>>
>>
>>
>> Rod Johnson wrote:
>>
>>> It seems to be a NoClassDefFoundError, and it affects mainly the 
>>> Hibernate
>>> call to config.buildSessionFactory() and anything to do with CGLIB.
>>>
>>> I don't have time to dig deeper right now, but does anyone have any 
>>> tips?
>>>
>>> Regards,
>>> Rod
>>

Re: [Springframework-developer] reloading/hot swapping of beans

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

While your on the topic of reloading / hot swapping of beans, what are your
thoughts on JMX?  Reloading / hot swapping of beans & JMX would go nicely
together.

I've been thinking a bit about Spring & JMX lately.  My original plan was to
implement some sort of a custom configuration repository that the JMX Mbeans
could update.  A database or the like.

Once the configuation changes were made, I would somehow signal my app.  The
app would load a second instance of spring, and then "swap" it with the
original at the appropriate time in the applications cycle.  Spring would be
used as a "factory" for all the objects in the application, and thus when
the new spring instance was loaded the new configuration would be used.  I
would use some sort of unit of work pattern to maintain a reference to the
"old" spring instance until that unit of work was completed so there would
be no issues with the config changing halfway through.

The primary issue I had with this setup is singletons.  If I have two
instances of Spring, then I don't have a true singleton anymore (I could
always revert to the "singleton" pattern if need be - yuck).  This may be
fine in some situations, but not ok in others.  Also, I would like some way
to "copy" state from the old singleton into the new one built into the
framework.

I just wanted to get this out there to see what people think about how to go
about JMX enabling spring.  Rod had said he had some thoughts on it a while
ago (or in his book?).

I haven't done a very good job of explaining this, but I think this would
work.  I can explain it better later if this is an area of interest to
people.

Later
Rob

> Yes, I think we could do this pretty easily. But I wouldn't want it to be
> the default.
>
> Regards,
> Rod
>

Re: [Springframework-developer] reloading/hot swapping of beans

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

Yes, I think we could do this pretty easily. But I wouldn't want it to be
the default.

Regards,
Rod

----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Monday, November 17, 2003 8:21 PM
Subject: [Springframework-developer] reloading/hot swapping of beans


> This is only of use in certain scenarios, but we should maybe examine
> the possibilities w/regards to unloading and reloading of beans. Both
> HiveMind and now Pico
>   http://www.picocontainer.org/hotswapping.html
> allow reloading of a bean/component returned from the container, due to
> the fact they they automatically introduce a dynamic proxy for the
> object returned form the container.
>
> This has a slight performance impact, but is probably the easiest way to
> handle reloading. Now how much additional
> complexity/variability/breakage this could introduce is I think pretty
> hard to figure out, given the amount of stuff you can do now with things
> like the BeanPostProcessor which can affect the lifecycle of a bunch of
> things in the container.
>
>
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>