springframework-developer — Spring Framework developers list

[Springframework-developer] Spring Framework 1.0.1 released

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

Dear Spring community,
=20
I'm pleased to announce that Spring Framework 1.0.1 has just been =
released. This is a bugfix and minor enhancement release; the most =
important fixes and new features are:
=20
* added Struts ActionSupport and DispatchActionSupport base classes, for =
easy access to a Spring context
* added Struts ContextLoaderPlugIn and DelegatingActionProxy, =
superseding Don Brown's Spring Struts Plugin
* reworked ComponentControllerSupport class for Tiles to be compatible =
with both Struts 1.1 and Struts 1.2
=20
* fixed Hibernate/JTA synchronization cleanup in case of Hibernate =
flushing failure on commit
* added support for transaction-scoped Hibernate Sessions with plain JTA =
or EJB CMT, without JtaTransactionManager
* fixed JdbcTemplate's "queryForList" to correctly handle a single row =
with a single column as result
=20
* XmlApplicationContexts support file patterns as config locations (e.g. =
"/WEB-INF/*-context.xml")
* SQLErrorCodesFactory caches database product name to avoid unnecessary =
metadata lookups
* factored out message code resolution into MessageCodesResolver =
strategy
=20
* refined internals of the AOP framework, for clearer subpackage =
interdependencies
* refined support for array/List/Map properties in BeanWrapperImpl
* refined AbstractMessageSource internals, for clearer handling of =
fallbacks
=20
As always, see the changelog for details.
=20
We particularly encourage users of Spring's Hibernate/JTA integration to =
update promptly, to avoid any issues in case of flushing failures. =
Furthermore, users of Don Brown's Spring Struts Plugin are encouraged to =
switch to the new integration classes.
=20
Regards,
=20
Juergen

RE: [Springframework-developer] SpringEnabledTestCase

[Choy R. <ch...@rc...>]

Confluence looks a pretty full-featured wiki/documentation/collaboration
tool. Like a wiki, you can edit any page. Unlike your average wiki, You
can watch a page or a space and be notified when someone changes it.

And the code formatting and searchability are just great. Try it:

http://opensource.atlassian.com/confluence/spring/homepage.action

type "test case" in the Quick Search box.

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On
Behalf
> Of Ronald Haring
> Sent: Wednesday, April 21, 2004 10:59 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] SpringEnabledTestCase
> 
> Personally I am not a big fan of wiki and wiki-like app, so I would
not
> like to see the discussions moved there.
> The other reason why I dont want it (exlusive) on wiki is that the
> mailling list doesnt require me to go to a page and check on the
ongoing
> discussions, it just arrives in my mail and I can read it anytime.
> 
> Cheers
> Ronald
> 
> Kopylenko, Dmitry wrote:
> 
> >Bob,
> >
> >I've added your post as a page in Spring-discuss space in our
Confluence.
> >
> >Let's start using Confluence more for these kinds of things.
> >
> >Regards,
> >Dmitriy.
> >
> >
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Final preparations for 1.0.1

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

If we're going to need 1.0.2 anyway, I'd say release 1.0.1 tonight.
Otherwise, I would like to commit my CGLIB fix right away so we have a we=
ek
to test it in the wild before a 1.0.1 release next week.

Ideally I'd feel more comfortable if we weren't changing things (even min=
or
stuff) so close to the release date. I'm keen on a code freeze of at leas=
t a
few days before each maintenance release.

Regards,
Rod

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Tuesday, April 20, 2004 10:57 PM
Subject: [Springframework-developer] Final preparations for 1.0.1


Everybody,

I've just committed the name change in the AOP package that we've discuss=
ed
a while ago, namely AbstractPrototypeTargetSource ->
AbstractPrototypeBasedTargetSource.

There's still two further minor enhancements that I'd like to look at, so
the question is how urgent 1.0.1 actually is. We've got two options: eith=
er
release 1.0.1 tomorrow evening, with everything that's in CVS by then, or
release it early next week, with those further issues addressed too. Of
course, new issues might get reported in the meantime again, so I'm somew=
hat
inclined to still release 1.0.1 tomorrow, and do a 1.0.2 release in a cou=
ple
of weeks.

I'd like to clarify the JdbcUtils.extractDatabaseMetaData issue in any ca=
se
for 1.0.1, as we need to get that released API right.

Juergen


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: Spring IDE - Eclipse Plugin: Migration of SpringUI finished; Version 1.0.0 ready

[Torsten J. <tju...@ya...>]

Rob,

thanx for pointing to Eclipse's bugzilla entry
regarding the Xerces plugin. This entry states that
after 2004-04-02 Eclipse 3.0 SDK will ship WITHOUT the
org.apache.xerces plug-in.

Hhm, bad news for the Spring Beans UI plugin. This
results in "bring your own" DOM level 3 compliant
parser (IMHO the implementation shipped with the
current JDK 1.4.2 does not support the DOM Level 3
API).


Btw. does anyone know a DOM Level 3 comliant XML
parser with a small footprint for re-distribution with
the Spring Beans plugin?
Shipping Xerces with the plugin-in is not a good
option :-(

Cheers,
Torsten


--- Rob Moore <Rob...@pe...> wrote:
> Just to follow up, this may be related to the
> following issue:
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=37696
> 
> I have emf (http://eclipse.org/emf/) installed and
> it may be specifying 
> the xerces plugin. Just a hunch.
> 
> Rob
> 
> Rob Moore wrote:
> > Hi, Torsten,
> > 
> > Thanks for looking into this. I'm unable to
> determine where the 
> > XMLParserConfiguration is being set. It is not in
> the command line (as 
> > you suggested). I'm thinking that another plug-in
> may be setting it (I'm 
> > using a trial of oXygen xml editor, so perhaps
> that's the culprit.
> > 
> > Rob
> > 
> > Torsten Juergeleit wrote:
> > 
> >> Rob,
> >>
> >> in your system summary the JVM system property
> >>
>
"org.apache.xerces.xni.parser.XMLParserConfiguration"
> >> is defined. This property overrides the same
> property
> >> defined in xercesImpl.jar (META-INF/services/)
> which
> >> references the (correct) class
> >>
>
"org.apache.xerces.parsers.StandardParserConfiguration".
> >> The class referenced in your (manually set)
> system
> >> property references the class
> >>
>
"org.apache.xerces.parsers.XIncludeParserConfiguration"
> >> which is not available in Eclipse's Xerces
> >> implementation.
> >>
> >> I have successfully reproduced your error by
> adding
> >> this invalid system property to the launch
> >> configuration of an Eclipse workbench (first tab
> "(x)
> >> Arguments", input field "VM Arguments").
> >>
> >>
> >> You have to get rid of this invalid system
> property
> >> (listed in Eclipse's system summary) to run
> Spring IDE
> >> Beans UI. Maybe it's defined in your Eclipse
> shortcut
> >> on the windows desktop (as commandline parameter
> >>
>
"-Dorg.apache.xerces.xni.parser.XMLParserConfiguration=org.apache.xerces.parsers.XIncludeParserConfiguration".
> 
> >>
> >>
> >> Cheers,
> >> Torsten
> > 
> > 
> > 
> >
>
-------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux
> Tutorials
> > Free Linux tutorial presented by Daniel Robbins,
> President and CEO of
> > GenToo technologies. Learn everything from
> fundamentals to system
> >
>
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux
> Tutorials
> Free Linux tutorial presented by Daniel Robbins,
> President and CEO of
> GenToo technologies. Learn everything from
> fundamentals to system
>
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer



	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash

[Springframework-developer] Re: Spring IDE - Eclipse Plugin: Migration of SpringUI finished; Version 1.0.0 ready

[Rob M. <Rob...@pe...>]

Just to follow up, this may be related to the following issue:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=37696

I have emf (http://eclipse.org/emf/) installed and it may be specifying 
the xerces plugin. Just a hunch.

Rob

Rob Moore wrote:
> Hi, Torsten,
> 
> Thanks for looking into this. I'm unable to determine where the 
> XMLParserConfiguration is being set. It is not in the command line (as 
> you suggested). I'm thinking that another plug-in may be setting it (I'm 
> using a trial of oXygen xml editor, so perhaps that's the culprit.
> 
> Rob
> 
> Torsten Juergeleit wrote:
> 
>> Rob,
>>
>> in your system summary the JVM system property
>> "org.apache.xerces.xni.parser.XMLParserConfiguration"
>> is defined. This property overrides the same property
>> defined in xercesImpl.jar (META-INF/services/) which
>> references the (correct) class
>> "org.apache.xerces.parsers.StandardParserConfiguration".
>> The class referenced in your (manually set) system
>> property references the class
>> "org.apache.xerces.parsers.XIncludeParserConfiguration"
>> which is not available in Eclipse's Xerces
>> implementation.
>>
>> I have successfully reproduced your error by adding
>> this invalid system property to the launch
>> configuration of an Eclipse workbench (first tab "(x)
>> Arguments", input field "VM Arguments").
>>
>>
>> You have to get rid of this invalid system property
>> (listed in Eclipse's system summary) to run Spring IDE
>> Beans UI. Maybe it's defined in your Eclipse shortcut
>> on the windows desktop (as commandline parameter
>> "-Dorg.apache.xerces.xni.parser.XMLParserConfiguration=org.apache.xerces.parsers.XIncludeParserConfiguration". 
>>
>>
>> Cheers,
>> Torsten
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: [Springframework-developer] SpringEnabledTestCase

[Ronald H. <ro...@co...>]

Personally I am not a big fan of wiki and wiki-like app, so I would not 
like to see the discussions moved there.
The other reason why I dont want it (exlusive) on wiki is that the 
mailling list doesnt require me to go to a page and check on the ongoing 
discussions, it just arrives in my mail and I can read it anytime.

Cheers
Ronald

Kopylenko, Dmitry wrote:

>Bob,
>
>I've added your post as a page in Spring-discuss space in our Confluence.
>
>Let's start using Confluence more for these kinds of things.
>
>Regards,
>Dmitriy.
>
>  
>

[Springframework-developer] Re: SpringEnabledTestCase

[Bob N. <rn...@co...>]

Hi Colin,

That's a good point. Currently none of my contexts have that kind of 
overhead, so I've not hit this in practise (yet!).

I confess I wasn't aware of the ResourceManager extension but my concern 
with sharing the app context is one of test isolation. One thing I do to 
get higher test coverage is to inject mock objects within the setUp() of 
my concrete test classes (in order to throw IOException's, for example). 
This would break tests if I were not tearing the context down each time. 
I suppose the correct way is to configure the mock objects in the 
context, of course. :)

I think a useful enhancement to my class is to make it easier to specify 
  test-specific configuration, rather than testcase-specific. This would 
then let me reuse existing application contexts for the higher levels. I 
could also then remove my programmatic configuration of beans for those 
cases where I test failure states.

B.

Colin Sampaleanu wrote:
> Hi Bob,
> 
> This is a useful approach and class. My only comment is that depending 
> on what is set up inside the ApplicationContext, the startup time for 
> creating the appcontext is long enough (even 5 seconds is pretty long) 
> that it may be overkill to set up the context for every single test, 
> especially given the fact that the context is relatively static and 
> contains singletons or produces new beans as prototypes. In that 
> respect, sharing an application context instance for all tests within a 
> TestCase can end up saving a lot of time across a whole project full of 
> TestCases. When you get into more 'integration' type tests that do 
> something like start up a Hibernate SessionFactory, it _really_ saves a 
> lot of time.
> 
> What I do to share an appcontext across a whole TestCase, is use some 
> helper classes from the junit extensions package, as follows:
> 
> ...
>  // --- attributes
>  // per-TestSuite specific vars, via ResourceManager!
>  ApplicationContext appContext;
> ...
> 
>  public static Test suite() {
>    return new TestSetup(new TestSuite(BasicMappedPersistenceTest.class)) {
> 
>      protected void setUp() throws Exception {
>        try {
>          ApplicationContext appContext;
>          appContext = new ClassPathXmlApplicationContext(new String[] 
> {CONTEXT, MAPPER_CONTEXT});
>          ResourceManager.addResource(APP_CONTEXT_ID, appContext);
>        }
>        catch (RuntimeException t) {
>          // just for debugging since Eclipse swallows these
>          throw t;
>        }
>        catch (Error e) {
>          // just for debugging since Eclipse swallows these
>          throw e;
>        }
>      }
> 
>      protected void tearDown() throws Exception {
>        ResourceManager.removeResource(APP_CONTEXT_ID);
>      }
>    };
>  }
> 
>  protected void setUp() throws Exception {
>    appContext = (ApplicationContext) 
> ResourceManager.getResource(APP_CONTEXT_ID);
>  }
>  protected void tearDown() throws Exception {
>    appContext = null;
>  }
> 
> 
> Essentially the junit extensions ResourceManager class allows you to 
> share certain object instances across the whole TestCase. This approach 
> would of course also probably work when assembling a test suite out of a 
> whole bunch of testcases.
> 
> Regards,
> Colin
> 
> 
> Bob Newson wrote:
> 
>> Hi,
>>
>> I've been experimenting with the Spring Framework since November. I've 
>> been using Spring in conjunction with JUnit in order to more easily 
>> wire up my testcases. I've not see this approach mentioned on the 
>> mailing lists, so I thought I'd share what I have (for reference, my 
>> test application is 4000 lines of code and I have 94.1% code coverage 
>> by Clover's measure, partly because this approach makes it much easier 
>> to factor out common tests and apply them).
>>
>> Basically, all of my TestCases's extend AbstractSpringEnabledTestCase 
>> (this, in turn extends an AbstractTestCase which extends 
>> junit.framework.TestCase, so that non-spring extensions can be added). 
>> This class, as part of setUp() and tearDown() attempts to load XML 
>> files with the same name as the testcases class and all of its 
>> parents. This allowed me to easily wire up my test fixtures. As a very 
>> useful side effect, this also persuaded me to factor out some of the 
>> commonalities in my testcases to form a hierarchy.
>>
>> Essentially, for each interface I had defined, I've ended up with an 
>> Abstract<Interface>TestCase with a corresponding 
>> Abstract<Interface>TestCase.xml with common wiring requirements. Where 
>> I have multiple implementations of a given interface it is often only 
>> necessary to create a concrete extension and simply inherit the test 
>> suite and its configuration.
>>
>> I'm interesting if anyone thinks this is a useful approach (or is it 
>> too obvious?). I'm also interested if anyone thinks it's a bad idea!
>>
>> I've appended the full source of AbstractSpringEnabledTestCase below. 
>> If anyone wants a more complete example, I could spend some time on that.
>>
>> A typical use of this class is to extend it, add a Spring 
>> configuration file named after the new concrete test case, and then 
>> access the context with the protected getContext() method.
>>
>> Regards,
>> Robert Newson.
>>
>> /*
>>  * Created on 23-Nov-2003
>>  */
>> package com.connected.junit.spring;
>>
>> import java.io.IOException;
>> import java.net.URL;
>> import java.util.ArrayList;
>> import java.util.List;
>>
>> import org.springframework.context.support.AbstractApplicationContext;
>> import 
>> org.springframework.context.support.ClassPathXmlApplicationContext;
>>
>> import com.connected.junit.AbstractTestCase;
>>
>> /**
>>  * For a given TestCase, we will load the following Spring contexts;
>>  * applicationContext.xml - the root context.
>>  * <package>/<classname>.xml - The context for the test case.
>>  * all parent classes of test case are also searched.
>>  * @author rnewson
>>  */
>> public abstract class AbstractSpringEnabledTestCase extends 
>> AbstractTestCase {
>>
>>     private AbstractApplicationContext context;
>>         protected ApplicationContext getContext() {
>>         return context;
>>     }
>>
>>     protected void setUp() throws Exception {
>>         super.setUp();
>>
>>         context = null;
>>         List classHierarchy = getClassHierarchy();
>>         for (int i = classHierarchy.size() - 1; i >= 0; i--) {
>>             Class clazz = (Class) classHierarchy.get(i);
>>             context =
>>                 getApplicationContext(
>>                     clazz,
>>                     getClassName(clazz) + ".xml",
>>                     context);
>>         }
>>     }
>>
>>     protected void tearDown() throws Exception {
>>         if (context != null) {
>>             context.close();
>>         }
>>     }
>>
>>     private List getClassHierarchy() {
>>         List result = new ArrayList();
>>         Class superclass = getClass();
>>         do {
>>             result.add(superclass);
>>         } while ((superclass = superclass.getSuperclass()) != null);
>>         return result;
>>     }
>>
>>     private String getClassName(Class clazz) {
>>         String fullClassName = clazz.getName();
>>         String result =
>>             fullClassName.substring(fullClassName.lastIndexOf(".") + 1);
>>         return result;
>>     }
>>
>>     private AbstractApplicationContext getApplicationContext(
>>         Class clazz,
>>         String resourceName,
>>         AbstractApplicationContext parentContext)
>>         throws IOException {
>>         URL url = clazz.getResource(resourceName);
>>
>>         if (url == null) {
>>             return parentContext;
>>         }
>>
>>         return new ClassPathXmlApplicationContext(
>>             new String[] { url.toString()},
>>             parentContext);
>>     }
>> }
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

RE: [Springframework-developer] SpringEnabledTestCase

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

Bob,

I've added your post as a page in Spring-discuss space in our Confluence.

Let's start using Confluence more for these kinds of things.

Regards,
Dmitriy.

-----Original Message-----
From: Bob Newson [mailto:rn...@co...] 
Sent: Wednesday, April 21, 2004 9:36 AM
To: spr...@li...
Subject: [Springframework-developer] SpringEnabledTestCase


Hi,

I've been experimenting with the Spring Framework since November. I've 
been using Spring in conjunction with JUnit in order to more easily wire 
up my testcases. I've not see this approach mentioned on the mailing 
lists, so I thought I'd share what I have (for reference, my test 
application is 4000 lines of code and I have 94.1% code coverage by 
Clover's measure, partly because this approach makes it much easier to 
factor out common tests and apply them).

Basically, all of my TestCases's extend AbstractSpringEnabledTestCase 
(this, in turn extends an AbstractTestCase which extends 
junit.framework.TestCase, so that non-spring extensions can be added). 
This class, as part of setUp() and tearDown() attempts to load XML files 
with the same name as the testcases class and all of its parents. This 
allowed me to easily wire up my test fixtures. As a very useful side 
effect, this also persuaded me to factor out some of the commonalities 
in my testcases to form a hierarchy.

Essentially, for each interface I had defined, I've ended up with an 
Abstract<Interface>TestCase with a corresponding 
Abstract<Interface>TestCase.xml with common wiring requirements. Where I 
have multiple implementations of a given interface it is often only 
necessary to create a concrete extension and simply inherit the test 
suite and its configuration.

I'm interesting if anyone thinks this is a useful approach (or is it too 
obvious?). I'm also interested if anyone thinks it's a bad idea!

I've appended the full source of AbstractSpringEnabledTestCase below. If 
anyone wants a more complete example, I could spend some time on that.

A typical use of this class is to extend it, add a Spring configuration 
file named after the new concrete test case, and then access the context 
with the protected getContext() method.

Regards,
Robert Newson.

/*
  * Created on 23-Nov-2003
  */
package com.connected.junit.spring;

import java.io.IOException;
import java.net.URL;
import java.util.ArrayList;
import java.util.List;

import org.springframework.context.support.AbstractApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

import com.connected.junit.AbstractTestCase;

/**
  * For a given TestCase, we will load the following Spring contexts;
  * applicationContext.xml - the root context.
  * <package>/<classname>.xml - The context for the test case.
  * all parent classes of test case are also searched.
  * @author rnewson
  */
public abstract class AbstractSpringEnabledTestCase extends 
AbstractTestCase {

	private AbstractApplicationContext context;
	
	protected ApplicationContext getContext() {
		return context;
	}

	protected void setUp() throws Exception {
		super.setUp();

		context = null;
		List classHierarchy = getClassHierarchy();
		for (int i = classHierarchy.size() - 1; i >= 0; i--) {
			Class clazz = (Class) classHierarchy.get(i);
			context =
				getApplicationContext(
					clazz,
					getClassName(clazz) + ".xml",
					context);
		}
	}

	protected void tearDown() throws Exception {
		if (context != null) {
			context.close();
		}
	}

	private List getClassHierarchy() {
		List result = new ArrayList();
		Class superclass = getClass();
		do {
			result.add(superclass);
		} while ((superclass = superclass.getSuperclass()) != null);
		return result;
	}

	private String getClassName(Class clazz) {
		String fullClassName = clazz.getName();
		String result =
	
fullClassName.substring(fullClassName.lastIndexOf(".") + 1);
		return result;
	}

	private AbstractApplicationContext getApplicationContext(
		Class clazz,
		String resourceName,
		AbstractApplicationContext parentContext)
		throws IOException {
		URL url = clazz.getResource(resourceName);

		if (url == null) {
			return parentContext;
		}

		return new ClassPathXmlApplicationContext(
			new String[] { url.toString()},
			parentContext);
	}
}



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] SpringEnabledTestCase

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

Hi Bob,

This is a useful approach and class. My only comment is that depending 
on what is set up inside the ApplicationContext, the startup time for 
creating the appcontext is long enough (even 5 seconds is pretty long) 
that it may be overkill to set up the context for every single test, 
especially given the fact that the context is relatively static and 
contains singletons or produces new beans as prototypes. In that 
respect, sharing an application context instance for all tests within a 
TestCase can end up saving a lot of time across a whole project full of 
TestCases. When you get into more 'integration' type tests that do 
something like start up a Hibernate SessionFactory, it _really_ saves a 
lot of time.

What I do to share an appcontext across a whole TestCase, is use some 
helper classes from the junit extensions package, as follows:

...
  // --- attributes
  // per-TestSuite specific vars, via ResourceManager!
  ApplicationContext appContext;
...

  public static Test suite() {
    return new TestSetup(new TestSuite(BasicMappedPersistenceTest.class)) {

      protected void setUp() throws Exception {
        try {
          ApplicationContext appContext;
          appContext = new ClassPathXmlApplicationContext(new String[] 
{CONTEXT, MAPPER_CONTEXT});
          ResourceManager.addResource(APP_CONTEXT_ID, appContext);
        }
        catch (RuntimeException t) {
          // just for debugging since Eclipse swallows these
          throw t;
        }
        catch (Error e) {
          // just for debugging since Eclipse swallows these
          throw e;
        }
      }

      protected void tearDown() throws Exception {
        ResourceManager.removeResource(APP_CONTEXT_ID);
      }
    };
  }

  protected void setUp() throws Exception {
    appContext = (ApplicationContext) 
ResourceManager.getResource(APP_CONTEXT_ID);
  }
  protected void tearDown() throws Exception {
    appContext = null;
  }


Essentially the junit extensions ResourceManager class allows you to 
share certain object instances across the whole TestCase. This approach 
would of course also probably work when assembling a test suite out of a 
whole bunch of testcases.

Regards,
Colin


Bob Newson wrote:

> Hi,
>
> I've been experimenting with the Spring Framework since November. I've 
> been using Spring in conjunction with JUnit in order to more easily 
> wire up my testcases. I've not see this approach mentioned on the 
> mailing lists, so I thought I'd share what I have (for reference, my 
> test application is 4000 lines of code and I have 94.1% code coverage 
> by Clover's measure, partly because this approach makes it much easier 
> to factor out common tests and apply them).
>
> Basically, all of my TestCases's extend AbstractSpringEnabledTestCase 
> (this, in turn extends an AbstractTestCase which extends 
> junit.framework.TestCase, so that non-spring extensions can be added). 
> This class, as part of setUp() and tearDown() attempts to load XML 
> files with the same name as the testcases class and all of its 
> parents. This allowed me to easily wire up my test fixtures. As a very 
> useful side effect, this also persuaded me to factor out some of the 
> commonalities in my testcases to form a hierarchy.
>
> Essentially, for each interface I had defined, I've ended up with an 
> Abstract<Interface>TestCase with a corresponding 
> Abstract<Interface>TestCase.xml with common wiring requirements. Where 
> I have multiple implementations of a given interface it is often only 
> necessary to create a concrete extension and simply inherit the test 
> suite and its configuration.
>
> I'm interesting if anyone thinks this is a useful approach (or is it 
> too obvious?). I'm also interested if anyone thinks it's a bad idea!
>
> I've appended the full source of AbstractSpringEnabledTestCase below. 
> If anyone wants a more complete example, I could spend some time on that.
>
> A typical use of this class is to extend it, add a Spring 
> configuration file named after the new concrete test case, and then 
> access the context with the protected getContext() method.
>
> Regards,
> Robert Newson.
>
> /*
>  * Created on 23-Nov-2003
>  */
> package com.connected.junit.spring;
>
> import java.io.IOException;
> import java.net.URL;
> import java.util.ArrayList;
> import java.util.List;
>
> import org.springframework.context.support.AbstractApplicationContext;
> import 
> org.springframework.context.support.ClassPathXmlApplicationContext;
>
> import com.connected.junit.AbstractTestCase;
>
> /**
>  * For a given TestCase, we will load the following Spring contexts;
>  * applicationContext.xml - the root context.
>  * <package>/<classname>.xml - The context for the test case.
>  * all parent classes of test case are also searched.
>  * @author rnewson
>  */
> public abstract class AbstractSpringEnabledTestCase extends 
> AbstractTestCase {
>
>     private AbstractApplicationContext context;
>     
>     protected ApplicationContext getContext() {
>         return context;
>     }
>
>     protected void setUp() throws Exception {
>         super.setUp();
>
>         context = null;
>         List classHierarchy = getClassHierarchy();
>         for (int i = classHierarchy.size() - 1; i >= 0; i--) {
>             Class clazz = (Class) classHierarchy.get(i);
>             context =
>                 getApplicationContext(
>                     clazz,
>                     getClassName(clazz) + ".xml",
>                     context);
>         }
>     }
>
>     protected void tearDown() throws Exception {
>         if (context != null) {
>             context.close();
>         }
>     }
>
>     private List getClassHierarchy() {
>         List result = new ArrayList();
>         Class superclass = getClass();
>         do {
>             result.add(superclass);
>         } while ((superclass = superclass.getSuperclass()) != null);
>         return result;
>     }
>
>     private String getClassName(Class clazz) {
>         String fullClassName = clazz.getName();
>         String result =
>             fullClassName.substring(fullClassName.lastIndexOf(".") + 1);
>         return result;
>     }
>
>     private AbstractApplicationContext getApplicationContext(
>         Class clazz,
>         String resourceName,
>         AbstractApplicationContext parentContext)
>         throws IOException {
>         URL url = clazz.getResource(resourceName);
>
>         if (url == null) {
>             return parentContext;
>         }
>
>         return new ClassPathXmlApplicationContext(
>             new String[] { url.toString()},
>             parentContext);
>     }
> }

[Springframework-developer] SpringEnabledTestCase

[Bob N. <rn...@co...>]

Hi,

I've been experimenting with the Spring Framework since November. I've 
been using Spring in conjunction with JUnit in order to more easily wire 
up my testcases. I've not see this approach mentioned on the mailing 
lists, so I thought I'd share what I have (for reference, my test 
application is 4000 lines of code and I have 94.1% code coverage by 
Clover's measure, partly because this approach makes it much easier to 
factor out common tests and apply them).

Basically, all of my TestCases's extend AbstractSpringEnabledTestCase 
(this, in turn extends an AbstractTestCase which extends 
junit.framework.TestCase, so that non-spring extensions can be added). 
This class, as part of setUp() and tearDown() attempts to load XML files 
with the same name as the testcases class and all of its parents. This 
allowed me to easily wire up my test fixtures. As a very useful side 
effect, this also persuaded me to factor out some of the commonalities 
in my testcases to form a hierarchy.

Essentially, for each interface I had defined, I've ended up with an 
Abstract<Interface>TestCase with a corresponding 
Abstract<Interface>TestCase.xml with common wiring requirements. Where I 
have multiple implementations of a given interface it is often only 
necessary to create a concrete extension and simply inherit the test 
suite and its configuration.

I'm interesting if anyone thinks this is a useful approach (or is it too 
obvious?). I'm also interested if anyone thinks it's a bad idea!

I've appended the full source of AbstractSpringEnabledTestCase below. If 
anyone wants a more complete example, I could spend some time on that.

A typical use of this class is to extend it, add a Spring configuration 
file named after the new concrete test case, and then access the context 
with the protected getContext() method.

Regards,
Robert Newson.

/*
  * Created on 23-Nov-2003
  */
package com.connected.junit.spring;

import java.io.IOException;
import java.net.URL;
import java.util.ArrayList;
import java.util.List;

import org.springframework.context.support.AbstractApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

import com.connected.junit.AbstractTestCase;

/**
  * For a given TestCase, we will load the following Spring contexts;
  * applicationContext.xml - the root context.
  * <package>/<classname>.xml - The context for the test case.
  * all parent classes of test case are also searched.
  * @author rnewson
  */
public abstract class AbstractSpringEnabledTestCase extends 
AbstractTestCase {

	private AbstractApplicationContext context;
	
	protected ApplicationContext getContext() {
		return context;
	}

	protected void setUp() throws Exception {
		super.setUp();

		context = null;
		List classHierarchy = getClassHierarchy();
		for (int i = classHierarchy.size() - 1; i >= 0; i--) {
			Class clazz = (Class) classHierarchy.get(i);
			context =
				getApplicationContext(
					clazz,
					getClassName(clazz) + ".xml",
					context);
		}
	}

	protected void tearDown() throws Exception {
		if (context != null) {
			context.close();
		}
	}

	private List getClassHierarchy() {
		List result = new ArrayList();
		Class superclass = getClass();
		do {
			result.add(superclass);
		} while ((superclass = superclass.getSuperclass()) != null);
		return result;
	}

	private String getClassName(Class clazz) {
		String fullClassName = clazz.getName();
		String result =
			fullClassName.substring(fullClassName.lastIndexOf(".") + 1);
		return result;
	}

	private AbstractApplicationContext getApplicationContext(
		Class clazz,
		String resourceName,
		AbstractApplicationContext parentContext)
		throws IOException {
		URL url = clazz.getResource(resourceName);

		if (url == null) {
			return parentContext;
		}

		return new ClassPathXmlApplicationContext(
			new String[] { url.toString()},
			parentContext);
	}
}

Re: [Springframework-developer] SimpleRemoteSlsbInvokerInterceptor - create per method invocation

[Les A. H. <le...@ha...>]

Colin,

Awesome...thanks very much for the warning.  I haven't read the J2EE & EJB specs
in over a year, so much of this has eluded my memory.  Perhaps its time for a
refresher...

One last question.  Is the majority of the performance overhead for acquiring
EJB handles incurred upon looking up the home?  If so, that would explain
caching the home for later create() method calls.

If, once acquiring the home, calling the actual create() method is a relatively
minor performance hit in comparison to doing the JNDI home lookup, most of my
concerns have been alieviated.  This behavior may be app-server implementation
specific, so I don't know that such a question would be answered in the specs.

Les

Quoting Colin Sampaleanu <col...@ex...>:

> Careful, the handles are not guaranteed to be threadsafe. On top of
> that, some containers do ensure they are threadsafe, but serialize all
> access through them.
>
> I remember back in early 2000 or so someboy here though he'd be smart
> and cached a stateless session bean stub in the servlet application
> context. This was then used to handle _all_ requests. This was with
> WebLogic 5.1 if I remember. The app was heavily used, and the net effect
> was the the serialization limited requests to about 4-5 per second.
> Later on somebody took over to try to optimize the app. Along with some
> db tweaks, they upped the number of requests per second to over 70, and
> I know the serialization was responsible for a good portion of the slowdown.
>
> What would probably work is a pool. But I have a feeling in practice you
> won't gain very much. If the methoc call every hits the db you're
> talking one or two orders of magnitude more work for the db access than
> getting the stub.
>
>
> Les A. Hazlewood wrote:
>
> >Hiya folks,
> >
> >I was digging around in the source code and noticed that the
> >SimpleRemoteSlsbInvokerInterceptor "create"s a new EJB handle per method
> >invocation (via the newSessionBeanInstance() method in the parent
> >AbstractRemoteSlsbInvoker).
> >
> >Aren't there performance implications when creating a new remote handle
> _per_
> >method invocation?  It seems to me like the performance overhead (network
> >calls, garbage collection, etc) could be substantial if you reference many
> >ejb's in a system.
> >
> >Is there a fundamental reason why the stub returned upon calling create() is
> not
> >cached for further use?
> >
> >For my own personal use, I subclassed the
> >SimpleRemoteStatelessSessionProxyFactorybean and created a
> >CachingRemoteSlsbProxyFactoryBean.  This class caches the returned stub upon
> >the first call to newSessionBeanInstance() and then uses that stub for
> further
> >method invocations.
> >
> >Is there anything wrong with that approach?   I just want to make sure what
> I'm
> >doing doesn't violate any design principles...
> >
> >Thanks,
> >
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Final preparations for 1.0.1

[Thomas R. <tho...@tr...>]

I'm fine with a release tomorrow.  I have resolved the issues with 
DatabaseMetaDataCallbackHandler.

Thomas

jürgen höller [werk3AT] wrote:

>Everybody,
> 
>I've just committed the name change in the AOP package that we've discussed a while ago, namely AbstractPrototypeTargetSource -> AbstractPrototypeBasedTargetSource.
> 
>There's still two further minor enhancements that I'd like to look at, so the question is how urgent 1.0.1 actually is. We've got two options: either release 1.0.1 tomorrow evening, with everything that's in CVS by then, or release it early next week, with those further issues addressed too. Of course, new issues might get reported in the meantime again, so I'm somewhat inclined to still release 1.0.1 tomorrow, and do a 1.0.2 release in a couple of weeks.
> 
>I'd like to clarify the JdbcUtils.extractDatabaseMetaData issue in any case for 1.0.1, as we need to get that released API right.
> 
>Juergen
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>  
>

Re: [Springframework-developer] JdbcUtils.extractDatabaseMetaData

[Thomas R. <tho...@tr...>]

> 
>The javadoc of JdbcUtils.extractDatabaseMetaData says that the method will never throw an exception, but it still throws a MetaDataAccessException on any kind of failure. Shouldn't it simply log exceptions and return null?
>  
>
That must have been an old comment that I forgot to change.  I have 
modified it to reflect that this method does throw a checked exception 
since we can't rely on the exception translation to be initialized when 
this method is called.  This method is infrequently used and I'd rather 
force the use of a catch block instead of relying on calling code to 
check for a null returned.

> 
>Furthermore, why is the DatabaseMetaDataCallbackHandler interface in the jdbc.core package? It is just used in the jdbc.support package, which shouldn't depend on jdbc.core (just the other way round). Consequently, I suggest to move it to jdbc.support.
> 
>  
>
Good point.  I have moved it.

Thomas

Re: [Springframework-developer] Final preparations for 1.0.1

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

+1 for tomorrow=27s release

Regards=2C
Dmitriy=2E

----- Original Message -----
From=3A Colin Sampaleanu =3Ccolinml1=40exis=2Ecom=3E
Date=3A Tuesday=2C April 20=2C 2004 5=3A34 pm
Subject=3A Re=3A =5BSpringframework-developer=5D Final preparations for 1=
=2E0=2E1

=3E I=27m for tomorrow night=2C as the Hibernate sesson binding bug has =

=3E been =

=3E sitting around in the released version for a long time now=2C and =

=3E somebody =

=3E might get burned by it in production=2E But if other people want to =

=3E delay=2C =

=3E it=27s not the end of the world=2E
=3E =

=3E =

=3E j=C3=BCrgen h=C3=B6ller =5Bwerk3AT=5D wrote=3A
=3E =

=3E =3EEverybody=2C
=3E =3E =

=3E =3EI=27ve just committed the name change in the AOP package that we=27=
ve =

=3E discussed a while ago=2C namely AbstractPrototypeTargetSource -=3E =

=3E AbstractPrototypeBasedTargetSource=2E=3E =

=3E =3EThere=27s still two further minor enhancements that I=27d like to =

=3E look at=2C so the question is how urgent 1=2E0=2E1 actually is=2E We=27=
ve =

=3E got two options=3A either release 1=2E0=2E1 tomorrow evening=2C with =

=3E everything that=27s in CVS by then=2C or release it early next week=2C=
 =

=3E with those further issues addressed too=2E Of course=2C new issues =

=3E might get reported in the meantime again=2C so I=27m somewhat incline=
d =

=3E to still release 1=2E0=2E1 tomorrow=2C and do a 1=2E0=2E2 release in =
a =

=3E couple of weeks=2E
=3E =3E =

=3E =3EI=27d like to clarify the JdbcUtils=2EextractDatabaseMetaData issu=
e =

=3E in any case for 1=2E0=2E1=2C as we need to get that released API righ=
t=2E
=3E =3E =

=3E =3EJuergen
=3E =3E  =

=3E =3E
=3E =

=3E =

=3E =

=3E -------------------------------------------------------
=3E This SF=2ENet email is sponsored by=3A IBM Linux Tutorials
=3E Free Linux tutorial presented by Daniel Robbins=2C President and CEO =
of
=3E GenToo technologies=2E Learn everything from fundamentals to system
=3E administration=2Ehttp=3A//ads=2Eosdn=2Ecom/=3Fad=5Fid=1470=26alloc=5F=
id638=26op=3Dclick
=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
=3E Springframework-developer mailing list
=3E Springframework-developer=40lists=2Esourceforge=2Enet
=3E https=3A//lists=2Esourceforge=2Enet/lists/listinfo/springframework-de=
veloper
=3E 

Re: [Springframework-developer] Final preparations for 1.0.1

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

I'm for tomorrow night, as the Hibernate sesson binding bug has been=20
sitting around in the released version for a long time now, and somebody=20
might get burned by it in production. But if other people want to delay,=20
it's not the end of the world.


j=FCrgen h=F6ller [werk3AT] wrote:

>Everybody,
>=20
>I've just committed the name change in the AOP package that we've discus=
sed a while ago, namely AbstractPrototypeTargetSource -> AbstractPrototyp=
eBasedTargetSource.
>=20
>There's still two further minor enhancements that I'd like to look at, s=
o the question is how urgent 1.0.1 actually is. We've got two options: ei=
ther release 1.0.1 tomorrow evening, with everything that's in CVS by the=
n, or release it early next week, with those further issues addressed too=
. Of course, new issues might get reported in the meantime again, so I'm =
somewhat inclined to still release 1.0.1 tomorrow, and do a 1.0.2 release=
 in a couple of weeks.
>=20
>I'd like to clarify the JdbcUtils.extractDatabaseMetaData issue in any c=
ase for 1.0.1, as we need to get that released API right.
>=20
>Juergen
> =20
>

[Springframework-developer] Final preparations for 1.0.1

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

Everybody,
=20
I've just committed the name change in the AOP package that we've =
discussed a while ago, namely AbstractPrototypeTargetSource -> =
AbstractPrototypeBasedTargetSource.
=20
There's still two further minor enhancements that I'd like to look at, =
so the question is how urgent 1.0.1 actually is. We've got two options: =
either release 1.0.1 tomorrow evening, with everything that's in CVS by =
then, or release it early next week, with those further issues addressed =
too. Of course, new issues might get reported in the meantime again, so =
I'm somewhat inclined to still release 1.0.1 tomorrow, and do a 1.0.2 =
release in a couple of weeks.
=20
I'd like to clarify the JdbcUtils.extractDatabaseMetaData issue in any =
case for 1.0.1, as we need to get that released API right.
=20
Juergen

RE: [Springframework-developer] Tapestry FAQ link to Spring integration article broken

[David S. <ds...@le...>]

I fixed it.

Regards

D.

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On
Behalf
> Of Colin Sampaleanu
> Sent: Tuesday, April 20, 2004 3:39 PM
> To: tap...@ja...
> Cc: spr...@li...
> Subject: Re: [Springframework-developer] Tapestry FAQ link to Spring
> integration article broken
>=20
> Can one of the Tapestry committers fix the link to Spring-Tapestry
> integration doc? It's currently broken as the document was moved into
> the main spring manual. The correct link is down below.
>=20
> Thanks,
> Colin
>=20
> j=FCrgen h=F6ller [werk3AT] wrote:
>=20
> >Colin,
> >
> >The link to our website on
http://jakarta.apache.org/tapestry/faq.html is
> broken. We should tell Howard to change it to
> http://www.springframework.org/docs/reference/view.html#view-tapestry.
> >
> >
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] JdbcUtils.extractDatabaseMetaData

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

Thomas,
=20
The javadoc of JdbcUtils.extractDatabaseMetaData says that the method =
will never throw an exception, but it still throws a =
MetaDataAccessException on any kind of failure. Shouldn't it simply log =
exceptions and return null?
=20
Furthermore, why is the DatabaseMetaDataCallbackHandler interface in the =
jdbc.core package? It is just used in the jdbc.support package, which =
shouldn't depend on jdbc.core (just the other way round). Consequently, =
I suggest to move it to jdbc.support.
=20
Juergen
=20

Re: [Springframework-developer] Tapestry FAQ link to Spring integration article broken

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

Can one of the Tapestry committers fix the link to Spring-Tapestry=20
integration doc? It's currently broken as the document was moved into=20
the main spring manual. The correct link is down below.

Thanks,
Colin

j=FCrgen h=F6ller [werk3AT] wrote:

>Colin,
>=20
>The link to our website on http://jakarta.apache.org/tapestry/faq.html i=
s broken. We should tell Howard to change it to http://www.springframewor=
k.org/docs/reference/view.html#view-tapestry.
> =20
>

[Springframework-developer] Tapestry FAQ link to Spring integration article broken

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

Colin,
=20
The link to our website on http://jakarta.apache.org/tapestry/faq.html =
is broken. We should tell Howard to change it to =
http://www.springframework.org/docs/reference/view.html#view-tapestry.
=20
Juergen

Re: [Springframework-developer] SimpleRemoteSlsbInvokerInterceptor - create per method invocation

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

Careful, the handles are not guaranteed to be threadsafe. On top of 
that, some containers do ensure they are threadsafe, but serialize all 
access through them.

I remember back in early 2000 or so someboy here though he'd be smart 
and cached a stateless session bean stub in the servlet application 
context. This was then used to handle _all_ requests. This was with 
WebLogic 5.1 if I remember. The app was heavily used, and the net effect 
was the the serialization limited requests to about 4-5 per second. 
Later on somebody took over to try to optimize the app. Along with some 
db tweaks, they upped the number of requests per second to over 70, and 
I know the serialization was responsible for a good portion of the slowdown.

What would probably work is a pool. But I have a feeling in practice you 
won't gain very much. If the methoc call every hits the db you're 
talking one or two orders of magnitude more work for the db access than 
getting the stub.


Les A. Hazlewood wrote:

>Hiya folks,
>
>I was digging around in the source code and noticed that the
>SimpleRemoteSlsbInvokerInterceptor "create"s a new EJB handle per method
>invocation (via the newSessionBeanInstance() method in the parent
>AbstractRemoteSlsbInvoker).
>
>Aren't there performance implications when creating a new remote handle _per_
>method invocation?  It seems to me like the performance overhead (network
>calls, garbage collection, etc) could be substantial if you reference many
>ejb's in a system.
>
>Is there a fundamental reason why the stub returned upon calling create() is not
>cached for further use?
>
>For my own personal use, I subclassed the
>SimpleRemoteStatelessSessionProxyFactorybean and created a
>CachingRemoteSlsbProxyFactoryBean.  This class caches the returned stub upon
>the first call to newSessionBeanInstance() and then uses that stub for further
>method invocations.
>
>Is there anything wrong with that approach?   I just want to make sure what I'm
>doing doesn't violate any design principles...
>
>Thanks,
>  
>

[Springframework-developer] SimpleRemoteSlsbInvokerInterceptor - create per method invocation

[Les A. H. <le...@ha...>]

Hiya folks,

I was digging around in the source code and noticed that the
SimpleRemoteSlsbInvokerInterceptor "create"s a new EJB handle per method
invocation (via the newSessionBeanInstance() method in the parent
AbstractRemoteSlsbInvoker).

Aren't there performance implications when creating a new remote handle _per_
method invocation?  It seems to me like the performance overhead (network
calls, garbage collection, etc) could be substantial if you reference many
ejb's in a system.

Is there a fundamental reason why the stub returned upon calling create() is not
cached for further use?

For my own personal use, I subclassed the
SimpleRemoteStatelessSessionProxyFactorybean and created a
CachingRemoteSlsbProxyFactoryBean.  This class caches the returned stub upon
the first call to newSessionBeanInstance() and then uses that stub for further
method invocations.

Is there anything wrong with that approach?   I just want to make sure what I'm
doing doesn't violate any design principles...

Thanks,

Les

[Springframework-developer] Re: Spring IDE - Eclipse Plugin: Migration of SpringUI finished; Version 1.0.0 ready

[Rob M. <Rob...@pe...>]

Hi, Torsten,

Thanks for looking into this. I'm unable to determine where the 
XMLParserConfiguration is being set. It is not in the command line (as 
you suggested). I'm thinking that another plug-in may be setting it (I'm 
using a trial of oXygen xml editor, so perhaps that's the culprit.

Rob

Torsten Juergeleit wrote:
> Rob,
> 
> in your system summary the JVM system property
> "org.apache.xerces.xni.parser.XMLParserConfiguration"
> is defined. This property overrides the same property
> defined in xercesImpl.jar (META-INF/services/) which
> references the (correct) class
> "org.apache.xerces.parsers.StandardParserConfiguration".
> The class referenced in your (manually set) system
> property references the class
> "org.apache.xerces.parsers.XIncludeParserConfiguration"
> which is not available in Eclipse's Xerces
> implementation.
> 
> I have successfully reproduced your error by adding
> this invalid system property to the launch
> configuration of an Eclipse workbench (first tab "(x)
> Arguments", input field "VM Arguments").
> 
> 
> You have to get rid of this invalid system property
> (listed in Eclipse's system summary) to run Spring IDE
> Beans UI. Maybe it's defined in your Eclipse shortcut
> on the windows desktop (as commandline parameter
> "-Dorg.apache.xerces.xni.parser.XMLParserConfiguration=org.apache.xerces.parsers.XIncludeParserConfiguration".
> 
> Cheers,
> Torsten

[Springframework-developer] WebApplicationObjectSupport

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

I've just relaxed WebApplicationObjectSupport's context type check: It =
doesn't check for WebApplicationContext on initialization now but rather =
lazily on invocation of getWebApplicationContext respectively =
getServletContext/getTempDir. This facilitates easier unit testing.
=20
This change was inspired by Matt's recent efforts that he documented on =
the Spring Live blog. It's indeed easier to use a =
ClassPathXmlApplicationContext than to use a XmlWebApplicationContext: =
The former allows to specify direct classpath URLs as config location, =
and doesn't require a mock ServletContext.
=20
I'll commit this by tomorrow, to be included in Spring 1.0.1 (scheduled =
for Tuesday night).
=20
Juergen

Re: [Springframework-developer] A few more doc changes checked in

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

As there's still some polished stuff to commit, I won't do the 1.0.1 =
release tonight. (Haven't had much chance to work on it yet since I =
returned from my Prague trip.) I'll commit everything till tomorrow; I =
plan to do the actual release Tuesday night.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: So 18.04.2004 18:14
An: spr...@li...
Betreff: [Springframework-developer] A few more doc changes checked in



J=FCrgen,

I don't know if you're actually working on the 1.0.1 release (or even
still planning to put it out today), but I checked in some changes to
the beans chapter in the docs, so please make sure to include that
change if possible.

Regards,
Colin




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer