springframework-developer — Spring Framework developers list

[Springframework-developer] about the step-by-step tutorial

[Shining R. <shi...@gm...>]

Hi, all:
     I've translated the step-by-step tutorial by Thomas Risberg into Chine=
se.
     I don't know how to contact Thomas Risberg to make a link for my
document. And how to contribute this tutorial to the spring framework
community.
     Anyone can help?  Thanks in advance.

--
From <a href=3D"http://www.cnblogs.com/shiningray">ShiningRay</a> @ <a
href=3D"http://www.nirvanastudio.org">NirvanaStudio</a>

RE: [Springframework-developer] spring build.352 Build Successful

[Bram S. <br...@in...>]

Hi Seth,

Thanks for mentioning this.
We have fixed the problem.

Bram

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Seth Ladd
Sent: vrijdag 7 oktober 2005 6:47
To: spr...@li...
Subject: Re: [Springframework-developer] spring build.352 Build Successful

Just a head's up, I am getting a Forbidden error when I try to access
the below URL.

Seth

On 10/6/05, al...@in... <al...@in...> wrote:
> View results here ->
http://opensource.jteam.nl/build/buildresults/spring?log=log20051007001648Lb
uild.352


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] spring build.352 Build Successful

[Seth L. <set...@gm...>]

Just a head's up, I am getting a Forbidden error when I try to access
the below URL.

Seth

On 10/6/05, al...@in... <al...@in...> wrote:
> View results here -> http://opensource.jteam.nl/build/buildresults/spring=
?log=3Dlog20051007001648Lbuild.352

[Springframework-developer] spring build.352 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20051007001648Lbuild.352

Re: [Springframework-developer] Generics-enhanced Beans declaration?

[Lachezar D. <l.d...@gm...>]

 Hm.
Actually after reading your reply I found out, that I don't need to
specialize beans in Spring, and even autowire-by-type works...

The problem would arise when one tries to reuse a single generic bean as
multiple specialized properties, but that is completely out-of scope.

I had the vague idea, that one could use reflection to instantiate a
specialized instance of a generic class, but you clarified it for me...
Those are just compile-time extras.

Thank you.

Re: [Springframework-developer] Generics-enhanced Beans declaration?

[Juergen H. <ju...@in...>]

JDK 1.5 generics are essentially a compile-time construct, not a run-time
construct. We can't instantiate a class with a given generic type through
reflection: That only makes sense in Java source code, for strong typing at
compile time. At runtime, it's just a plain instance of that class. Hence,
we also can't autowire such beans by specific generic type: At runtime, the
generic type information is essentially not available anymore. All of those
instances can be just be matched again their plain class type.
 
In other words, classes using generics are not different from plain Java
classes at runtime, hence they cannot be (or need to be) treated in a
specific fashion by Spring.
 
In your specific case, you could essentially define a single
BaseHibernateDao and pass it to all your services, even if each of those
services expects a specifically typed BaseHibernateDao. At runtime, that
single plain BaseHibernateDao instance is gonna be able to serve all those
typed callers. It's all gonna be Object arguments at runtime, with the
specific types only mattering to the source code of the callers - as long as
the actual runtime Object type matches the caller's expectation.
 
Juergen
 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Lachezar Dobrev
Sent: Wednesday, October 05, 2005 10:15 AM
To: Spring DEV
Subject: [Springframework-developer] Generics-enhanced Beans declaration?


  << Appologies to all members that get this mail once more. >>
  << It seems SF drops mail from users with non-latin names :(. >>
  << I changed my name to be in latin letters only, hope it gets now. >>

  I did not invest much time in Google-ing around to find an answer, but
most of my findings were concerning something called "generics medicines"
and "until spring".
  
  I want to ask if there are any plans to support generics-enhanced beans
declarations in Spring Context.
  I don't quite grasp the idea there, but I think there 'might/should' be a
way to specialize a generic enhanced bean's class in the context, something
saying what classes is the generic specialized for.

  I have seen questions here as to what use would it be... 
  Well... Let's say we have a generic base DAO interface:

  public interface BaseDao<T> {
     public T    load(Long ID);
     public Long save(T);

     public void update(T);
     public void update(Collection<T>);

     public void delete(T);
     public void delete(Collection<T>);
     public void delete(Collection<Long>);
  }

  So we have our services depend on BaseDAO<SpecificType>

  public class MyServiceImpl implements MyService {
     // We specialise the generic type here.
     public void setBaseDao(BaseDao<SpecificEntity> dao) {
        this.dao = dao;
     }
  }

  Then let's assume we are using Hibernate and have a Generic implementation
of the BaseDao<T>: BaseHibernateDao<T>
  public class BaseHibernateDao<T> extends HibernateDaoSupport implements
BaseDao<T> {
     public T    load(Long ID) { ... }
     public Long save(T)       { ... }

     public void update(T)             { ... }
     public void update(Collection<T>) { ... }

     public void delete(T)                { ... }
     public void delete(Collection<T>)    { ... }
     public void delete(Collection<Long>) { ... }
  }

  1. I would very much like to do:
  <bean name="myEntityDao" 
    class="com.company.BaseHibernateDao<com.company.SpecificEntityClass>" />

  Actually I believe this is quite required if Spring is to be
Java5-capable.

  2. I would also want to have:
  <bean name="myService" 
    class="com.company.MyServiceImpl"
    autowire="byType"/>

  and of course have my baseDao set accordingly. This is not required, as
byName gives better handling, but might be considered good.

  These are not all the implications Generics support in Spring might give,
but I think these give some insight on what Generics can be used for.

  While Spring uses reflection and run-time-casting it would supply little
or no extras for Spring itself (I think), but enabling the use of Generics
for contained beans might provide some wishful flexibility.
  
  Thoughts for food :)

  Lachezar Dobrev 

[Springframework-developer] spring build.351 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20051006001706Lbuild.351

[Springframework-developer] Generics-enhanced Beans declaration?

[Lachezar D. <l.d...@gm...>]

 << Appologies to all members that get this mail once more. >>
<< It seems SF drops mail from users with non-latin names :(. >>
<< I changed my name to be in latin letters only, hope it gets now. >>

I did not invest much time in Google-ing around to find an answer, but most
of my findings were concerning something called "generics medicines" and
"until spring".

I want to ask if there are any plans to support generics-enhanced beans
declarations in Spring Context.
I don't quite grasp the idea there, but I think there 'might/should' be a
way to specialize a generic enhanced bean's class in the context, something
saying what classes is the generic specialized for.

I have seen questions here as to what use would it be...
Well... Let's say we have a generic base DAO interface:

public interface BaseDao<T> {
 public T load(Long ID);
 public Long save(T);

public void update(T);
public void update(Collection<T>);

public void delete(T);
 public void delete(Collection<T>);
public void delete(Collection<Long>);
 }

So we have our services depend on BaseDAO<SpecificType>

 public class MyServiceImpl implements MyService {
 // We specialise the generic type here.
 public void setBaseDao(BaseDao<SpecificEntity> dao) {
 this.dao =3D dao;
 }
 }

Then let's assume we are using Hibernate and have a Generic implementation
of the BaseDao<T>: BaseHibernateDao<T>
 public class BaseHibernateDao<T> extends HibernateDaoSupport
implementsBaseDao<T> {
 public T load(Long ID) { ... }
 public Long save(T) { ... }

public void update(T) { ... }
public void update(Collection<T>) { ... }

public void delete(T) { ... }
 public void delete(Collection<T>) { ... }
public void delete(Collection<Long>) { ... }
 }

1. I would very much like to do:
 <bean name=3D"myEntityDao"
 class=3D"com.company.BaseHibernateDao<com.company.SpecificEntityClass>" />

Actually I believe this is quite required if Spring is to be Java5-capable.

2. I would also want to have:
 <bean name=3D"myService"
 class=3D"com.company.MyServiceImpl"
 autowire=3D"byType"/>

and of course have my baseDao set accordingly. This is not required, as
byName gives better handling, but might be considered good.

These are not all the implications Generics support in Spring might give,
but I think these give some insight on what Generics can be used for.

While Spring uses reflection and run-time-casting it would supply little or
no extras for Spring itself (I think), but enabling the use of Generics for
contained beans might provide some wishful flexibility.

Thoughts for food :)

Lachezar Dobrev

[Springframework-developer] Ping.

[Lachezar D. <l.d...@gm...>]

 Please pardon this mail.
This is my (n+1)-th try to actualy send something.

I would ask anyone on the mail to PONG me privately so that I know that my
mails actualy got sent.

[Springframework-developer] spring build.350 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20051005001708Lbuild.350

[Springframework-developer] spring build.349 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20051004001632Lbuild.349

Re: [Springframework-developer] Road map for Spring 1.2.6 and 1.3 RC1

[<ro...@in...>]

I'm back at work tomorrow so I'll be able to close my 1.2.6 issues then
and on the train Wednesday. I'll take a browse through the rest and clean
up any as I can. I think Rick has some doc issues he wants to fix so I'll
see about him spending some time on that this week.

Rob

> Developers,
>
> It looks like we have gathered enough reported issues that justify a 1.2.6
> release. Most of them are rather minor and/or just affect specific
> deployment environments. We should nevertheless get proper fixes out early
> rather than wait for 1.3 final to get them out in production shape.
>
> See our current JIRA road map for details:
> http://opensource2.atlassian.com/projects/spring/browse/SPR?report=com.atlas
> sian.jira.plugin.system.project:roadmap-panel
>
> The current plan is to release 1.2.6 in about 2 weeks, with 1.3 RC1
> following 2 weeks afterwards. All relevant fixes, even if just doc fixes,
> should go into 1.2.6, with 1.3 RC1 being entirely focused on the new
> feature
> areas planned. No  fixes that can be achieved in 1.2.x should be deferred
> till 1.3.
>
> In terms of proceeding, I would suggest to let CVS HEAD remain at 1.2.x
> level for at least a further week, with 1.3 work continuing in the sandbox
> for the time being. Some major 1.3 feature areas (such as async JMS) are
> still not 100% finished, so there's still work to be done in the sandbox.
>
> Once all planned 1.2.6 fixes are done, I would suggest to create an actual
> 1.2 maintenance branch and dedicate CVS HEAD to 1.3 finalization. At this
> time, the relevant sandbox packages (Portlet support, async JMS, etc)
> should
> be moved over; by then, those packages should already be finished and
> polished.
>
> I'd like to encourage everybody to dedicate time to the remaining 1.2
> issues
> identified in JIRA! Of course, finishing the 1.3 feature areas in the
> sandbox is important and urgent as well. The above-mentioned release dates
> have to be considered as hard deadlines, to allow for 1.3 final to happen
> by
> late November.
>
> Juergen
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] DelegatingActionUtils for STRUTS

[Juergen H. <ju...@in...>]

Let me clarify the intentions here: DelegatingActionUtils's
getRequiredWebApplicationContext method *deliberately* only looks for the
ContextLoaderPlugIn-loaded context, as its intent is to look for Struts
Action bean definitions. Such Action beans don't belong in the root
application context but rather only in the Struts-specific
ContextLoaderPlugIn context.

As an aside: If you have both a root application context and a
ContextLoaderPlugIn context, the latter will automatically be a child of the
former and thus see all beans defined there. As a consequence, you can
easily pass service layer references (from the root context) into bean
properties of your Struts Action beans (defined in the ContextLoaderPlugIn
context).

I guess what you want to achieve is something different: You seem to use
DelegationActionUtils directly to fetch a reference to the Spring
WebApplicationContext, for custom bean access (that is, not for delegating
to Struts Action bean definitions). This is similar to what our
*ActionSupport classes do in their initWebApplicationContext implementation.

Hence, I've added a findRequiredWebApplicationContext method to
DelegatingActionUtils: first checking the Struts-specific context (loaded by
ContextLoaderPlugIn), then falling back to the root context (loaded by
ContextLoaderListener). That method is essentially factored out from
*ActionSupport but can also be used directly.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Velorider
Sent: Saturday, October 01, 2005 10:14 AM
To: spr...@li....
Subject: [Springframework-developer] DelegatingActionUtils for STRUTS

I ran across a problem when I tried to load the WebApplicationContext using
the ContextLoaderListener in a multi servlet, plus STRUTS environment.  When
loading the WebApplicationContext with the ContextLoaderListener the web app
context is stored at
WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE within the
servlet context. This prevents DelegatingActionUtils from finding the
context because it only expects the web app context to be loaded by the
ContextPlugin and stored at ContextLoaderPlugIn.SERVLET_CONTEXT_PREFIX. 

This is fine if only running a STRUTS application.  But larger applications
will include other servlets that require the web application context.  Of
coarse they could locate the web app context by looking for
ContextLoaderPlugIn.SERVLET_CONTEXT_PREFIX but this seems strange since it
STRUS spefic. Plus this requires that the STRUTS action servlet load first
so the Context plugin can initialize the web context before the other
servlets use it.

My fix was to add a check for the web context at WebApplicationContext. 
ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE before throwing the exception and
after looking in ContextLoaderPlugIn.SERVLET_CONTEXT_PREFIX.  This should
mentain backwards compatibility and allows the ContextLoaderListener to
initialize the web context for other servlet and still use Spring with
STRUTS.

Below is my patch for DelegatingActionUtils in 1.2.5.  Does this seems like
a good solution and if so how can it be submited.

Thanks
John

68a69,73
>   if (wac == null) {
>    wac = (WebApplicationContext)
actionServlet.getServletContext().getAttribute(WebApplicationContext.
>      ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);
>   }
>   


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] OracleLobHandler on WebSphere 6.0

[Juergen H. <ju...@in...>]

Odd mail order here... As I wrote in my actually latest mail, I have changed
OracleLobHandler to use a post-invocation ClassCastException check; already
committed to CVS.
 
Juergen
 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Juergen Hoeller
Sent: Sunday, October 02, 2005 11:15 PM
To: spr...@li...
Subject: Re: [Springframework-developer] OracleLobHandler on WebSphere 6.0


Yes... but I guess checking for the name starting with "oracle.jdbc." would
be fine. It's just about checking whether the passed-in Connection has any
chance of getting accepted by CLOB.createTemporary(con, ...) so we don't
really need a full type check there - just a basic sanity check.
 
Juergen
 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Thomas Risberg
Sent: Sunday, October 02, 2005 11:10 PM
To: spr...@li...
Subject: Re: [Springframework-developer] OracleLobHandler on WebSphere 6.0


We could also use the classloader for the connection to load any classes
used for testing and for reflection - like 

conToUse.getClass().getClassLoader().loadClass(CONNECTION_CLASS_NAME);

Thomas


On Oct 2, 2005, at 4:58 PM, Thomas Risberg wrote:



On Oct 2, 2005, at 4:43 PM, Juergen Hoeller wrote:



So our OracleLobHandler works on the new "oracle.jdbc.Connection" interface,
while WebSphere seems to return an "oracle.jdbc.driver.Connection" that's
not assignable to the "oracle.jdbc.Connection" interface.


The class we test for is:
private static final String CONNECTION_CLASS_NAME =
"oracle.jdbc.OracleConnection";

In my tests any Oracle connection is assignable to this class as long as
they both come from the same classloader.

Seems like the test is the problem here - maybe we should just test for a
class name that starts with "oracle.jdbc"

Thomas

[Springframework-developer] DelegatingActionUtils for STRUTS

[Velorider <vel...@pu...>]

I ran across a problem when I tried to load the WebApplicationContext using 
the ContextLoaderListener in a multi servlet, plus STRUTS environment.  When 
loading the WebApplicationContext with the ContextLoaderListener the web app 
context is stored at 
WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE within the 
servlet context. This prevents DelegatingActionUtils from finding the context 
because it only expects the web app context to be loaded by the ContextPlugin 
and stored at ContextLoaderPlugIn.SERVLET_CONTEXT_PREFIX. 

This is fine if only running a STRUTS application.  But larger applications 
will include other servlets that require the web application context.  Of 
coarse they could locate the web app context by looking for 
ContextLoaderPlugIn.SERVLET_CONTEXT_PREFIX but this seems strange since it 
STRUS spefic. Plus this requires that the STRUTS action servlet load first so 
the Context plugin can initialize the web context before the other servlets 
use it.

My fix was to add a check for the web context at WebApplicationContext. 
ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE before throwing the exception and 
after looking in ContextLoaderPlugIn.SERVLET_CONTEXT_PREFIX.  This should 
mentain backwards compatibility and allows the ContextLoaderListener to 
initialize the web context for other servlet and still use Spring with 
STRUTS.

Below is my patch for DelegatingActionUtils in 1.2.5.  Does this seems like a 
good solution and if so how can it be submited.

Thanks
John

68a69,73
>   if (wac == null) {
>    wac = (WebApplicationContext) 
actionServlet.getServletContext().getAttribute(WebApplicationContext.
>      ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);
>   }
>   

Re: [Springframework-developer] clover reports online anywhere?

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

Hi,

It should be building every day, but occasionally cruise control hangs
while accessing cvs and I don't notice for a few days (or more).
Sometimes jar version changes break the Maven build too but I try and
fix those periodically.

The clover information isn't exactly right because quite a few of the
tests which succeed in the ant build don't run correctly with Maven
(different paths etc.). I haven't had time to investigate the reasons
properly but if people are actually using the information then I'll try
and check it out.

Luke.

Darren Davison wrote:
> On Wed, Sep 28, 2005 at 02:01:38PM -1000, Seth Ladd wrote:
> 
> 
>>Thanks for the tip.  I was aware of that page, but never found the
>>clover reports.  It would be really nice to link to those after every
>>build.  Also, the JUnit HTML reports might be useful as well.
> 
> 
> Looks like Luke is still running them:
> http://www.monkeymachine.co.uk/spring/clover/index.html
> 
> Forgot about this earlier - don't know how often they get updated though.
> 
> Cheers!
> 
> 

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

Re: [Springframework-developer] Conditional configuration

[Farhan K. <ka...@gm...>]

Sorry I somehow clicked send without finishing my thoughts:
 ruwBeanRefContext.xml:
 <bean id=3D"base.application.context" class=3D"
org.springframework.context.ApplicationContextFactory">
 <property name=3D"implementationClass">
<value>org....ClassPathXmlApplicationContext</value>
</property>
<property name=3D"defaultIncludes">
<list>
<value>someContext1.xml</value>
<value>someContext2.xml</value>
</list>
</property>
<property name=3D"conditionalIncludes">
<list>
<ref bean=3D"integration-sales"/>
<ref bean=3D"integration-accountmanagement"/>
</list>
</property>
</bean>
 <bean id=3D"intgeration-sales" class=3D"
org.springframework.context.SystemConditionalInclude">
 <property name=3D"key" value=3D"sales"/>
 <property name=3D"liveDefinitionFiles">
 <list><value>IntegrationContext-sales.xml</value></list>
 </property>
 <property name=3D"stubbedFiles">
 <list><value>integrationContext-sales-stubbed</value</list>
 </property>
</bean>

 The SystemConditionalInclude would look for "sales" property as a System
Property to be set to true/live or not. It would implement
ConditionalInclude. Other implementations of ConditionalInclude could look
for keys in other ways.
 On 10/1/05, Farhan Kazmi <ka...@gm...> wrote:
>
> There are times when real conditional configuration is helpful. Consider
> an application that integrates with external systems with JMS.
>  If the integration module is not central to the application, you probabl=
y
> want this interface stubbed during development. One option is to have 2 s=
ets
> of bean definition files i.e. ApplicationContext-Integration.xml and
> ApplicationContext-Stubbed.xml. You could have ANT build tasks that
> included either the development (stubbed) version or the unstubbed versio=
n.
>  But what if you have not one, but many different interfaces to external
> systems. Any one of these may or may not be stubbed. We would need differ=
ent
> builds for each environment.
>  It is sometimes easier to have a single build of an ear file. The same
> EAR file goes to all environments. This makes life easier for in many way=
s
> and for many teams.
>  Right now, this capability is not provided with Spring, and is something
> you have to build yourself. I have an initial, very rough (and very verbo=
se)
> idea of how this could be done. How about something like this:
>  beanRefContext.xml file:
>  <bean id=3D"base.application.context"
>
>
>  On 9/27/05, Rob Butler <cro...@ya...> wrote:
> >
> > Excellent!
> >
> > Thank you.
> > Rob
> >
> > --- Juergen Hoeller < ju...@in...> wrote:
> >
> > > Actually, if you define two different
> > > implementations as lazy-init=3D"true",
> > > including all beans that they depend on, you will
> > > only actually instantiate
> > > the beans that you explicitly refer to. If you have
> > > a placeholder a la <ref
> > > bean=3D"${myTarget}"/>, only the actually referenced
> > > target bean and its
> > > dependencies will get instantiated.
> > >
> > > See the LobHandler definitions in our Image Database
> > > sample application for
> > > an example: The lazy-init flags there avoid to
> > > instantiate OracleLobHandler
> > > unless it is actually referenced by the DAO. That
> > > reference is expressed
> > > using a placeholder, so the actual choice can be
> > > driven by a properties
> > > file.
> > >
> > > If such lazy initialization becomes common in your
> > > bean definition file,
> > > consider setting default-lazy-init=3D"true" at the
> > > <beans> level, only
> > > selectively turning off the lazy-init flag for
> > > specific beans that you want
> > > to have eagerly instantiated at startup.
> > >
> > > Juergen
> > >
> > >
> > > -----Original Message-----
> > > From:
> > >
> > spr...@li...
> > >
> > [mailto:spr...@li...]
> > > On Behalf Of
> > > Rob Butler
> > > Sent: Saturday, September 24, 2005 4:32 AM
> > > To: spr...@li...
> > > Subject: [Springframework-developer] Conditional
> > > configuration
> > >
> > > Hey all,
> > >
> > > I was wondering if Spring could be enhanced to
> > > support "conditional
> > > configuration" or if there is a way to do this
> > > already that I haven't
> > > thought of.
> > >
> > > Let's say your app has a property file bean post
> > > processor. Depending upon
> > > a setting in the property file you want to switch
> > > between two different
> > > implementations of some interface - Impl1 & Impl2.
> > > No problem, Spring does
> > > this easily.
> > >
> > > But let's say those two different implementations
> > > also have a number of
> > > Spring managed beans injected into them. So if your
> > > using Impl2 then all
> > > the Spring managed beans that are injected into
> > > Impl1 aren't needed.
> > >
> > > Is there a way to have spring _not_ instatiate and
> > > configure some beans
> > > depending upon a value obtained from a bean post
> > > processor?
> > >
> > > If this doesn't already exit perhaps a new attribute
> > > can be added to the
> > > bean tag like "load" or "configure". If load=3D"true"
> > > then the bean is
> > > loaded.
> > > In this way Impl1 could be keyed to
> > > load=3D"${useImpl1}"
> > > and so could all of the Spring managed beans that
> > > would be injected into it.
> > > Thus, if useImpl1 was false Impl1 and all the
> > > objects constructed to support
> > > it would never be instantiated.
> > >
> > > It would also be preferable for references to bean
> > > post processor values
> > > that used in un-instantiated objects to no longer be
> > > necessary. I.E. if
> > > Impl1 has someSetter=3D"${someProperty}" and Impl1
> > > load=3D"false"
> > > then spring should not error if "someProperty" is
> > > not provided.
> > >
> > > Thoughts?
> > >
> > > Rob
> > >
> > >
> > >
> > > __________________________________
> > > Yahoo! Mail - PC Magazine Editors' Choice 2005
> > > http://mail.yahoo.com
> > >
> > >
> > >
> > -------------------------------------------------------
> > > SF.Net email is sponsored by:
> > > Tame your development challenges with Apache's
> > > Geronimo App Server. Download
> > > it for free - -and be entered to win a 42" plasma tv
> > > or your very own
> > > Sony(tm)PSP. Click here to play:
> > > http://sourceforge.net/geronimo.php
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > >
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > >
> > >
> > >
> > >
> > >
> > -------------------------------------------------------
> > > SF.Net email is sponsored by:
> > > Tame your development challenges with Apache's
> > > Geronimo App Server. Download
> > > it for free - -and be entered to win a 42" plasma tv
> > > or your very own
> > > Sony(tm)PSP. Click here to play:
> > > http://sourceforge.net/geronimo.php
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > >
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Power Architecture Resource Center: Free content, downloads,
> > discussions,
> > and more. http://solutions.newsforge.com/ibmarch.tmpl
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>

[Springframework-developer] Road map for Spring 1.2.6 and 1.3 RC1

[Juergen H. <ju...@in...>]

Developers,

It looks like we have gathered enough reported issues that justify a 1.2.6
release. Most of them are rather minor and/or just affect specific
deployment environments. We should nevertheless get proper fixes out early
rather than wait for 1.3 final to get them out in production shape.

See our current JIRA road map for details:
http://opensource2.atlassian.com/projects/spring/browse/SPR?report=com.atlas
sian.jira.plugin.system.project:roadmap-panel

The current plan is to release 1.2.6 in about 2 weeks, with 1.3 RC1
following 2 weeks afterwards. All relevant fixes, even if just doc fixes,
should go into 1.2.6, with 1.3 RC1 being entirely focused on the new feature
areas planned. No  fixes that can be achieved in 1.2.x should be deferred
till 1.3.

In terms of proceeding, I would suggest to let CVS HEAD remain at 1.2.x
level for at least a further week, with 1.3 work continuing in the sandbox
for the time being. Some major 1.3 feature areas (such as async JMS) are
still not 100% finished, so there's still work to be done in the sandbox.

Once all planned 1.2.6 fixes are done, I would suggest to create an actual
1.2 maintenance branch and dedicate CVS HEAD to 1.3 finalization. At this
time, the relevant sandbox packages (Portlet support, async JMS, etc) should
be moved over; by then, those packages should already be finished and
polished.

I'd like to encourage everybody to dedicate time to the remaining 1.2 issues
identified in JIRA! Of course, finishing the 1.3 feature areas in the
sandbox is important and urgent as well. The above-mentioned release dates
have to be considered as hard deadlines, to allow for 1.3 final to happen by
late November.

Juergen

Re: [Springframework-developer] Conditional configuration

[Farhan K. <ka...@gm...>]

There are times when real conditional configuration is helpful. Consider an
application that integrates with external systems with JMS.
 If the integration module is not central to the application, you probably
want this interface stubbed during development. One option is to have 2 set=
s
of bean definition files i.e. ApplicationContext-Integration.xml and
ApplicationContext-Stubbed.xml. You could have ANT build tasks that include=
d
either the development (stubbed) version or the unstubbed version.
 But what if you have not one, but many different interfaces to external
systems. Any one of these may or may not be stubbed. We would need differen=
t
builds for each environment.
 It is sometimes easier to have a single build of an ear file. The same EAR
file goes to all environments. This makes life easier for in many ways and
for many teams.
 Right now, this capability is not provided with Spring, and is something
you have to build yourself. I have an initial, very rough (and very verbose=
)
idea of how this could be done. How about something like this:
 beanRefContext.xml file:
 <bean id=3D"base.application.context"


 On 9/27/05, Rob Butler <cro...@ya...> wrote:
>
> Excellent!
>
> Thank you.
> Rob
>
> --- Juergen Hoeller <ju...@in...> wrote:
>
> > Actually, if you define two different
> > implementations as lazy-init=3D"true",
> > including all beans that they depend on, you will
> > only actually instantiate
> > the beans that you explicitly refer to. If you have
> > a placeholder a la <ref
> > bean=3D"${myTarget}"/>, only the actually referenced
> > target bean and its
> > dependencies will get instantiated.
> >
> > See the LobHandler definitions in our Image Database
> > sample application for
> > an example: The lazy-init flags there avoid to
> > instantiate OracleLobHandler
> > unless it is actually referenced by the DAO. That
> > reference is expressed
> > using a placeholder, so the actual choice can be
> > driven by a properties
> > file.
> >
> > If such lazy initialization becomes common in your
> > bean definition file,
> > consider setting default-lazy-init=3D"true" at the
> > <beans> level, only
> > selectively turning off the lazy-init flag for
> > specific beans that you want
> > to have eagerly instantiated at startup.
> >
> > Juergen
> >
> >
> > -----Original Message-----
> > From:
> >
> spr...@li...
> >
> [mailto:spr...@li...]
> > On Behalf Of
> > Rob Butler
> > Sent: Saturday, September 24, 2005 4:32 AM
> > To: spr...@li...
> > Subject: [Springframework-developer] Conditional
> > configuration
> >
> > Hey all,
> >
> > I was wondering if Spring could be enhanced to
> > support "conditional
> > configuration" or if there is a way to do this
> > already that I haven't
> > thought of.
> >
> > Let's say your app has a property file bean post
> > processor. Depending upon
> > a setting in the property file you want to switch
> > between two different
> > implementations of some interface - Impl1 & Impl2.
> > No problem, Spring does
> > this easily.
> >
> > But let's say those two different implementations
> > also have a number of
> > Spring managed beans injected into them. So if your
> > using Impl2 then all
> > the Spring managed beans that are injected into
> > Impl1 aren't needed.
> >
> > Is there a way to have spring _not_ instatiate and
> > configure some beans
> > depending upon a value obtained from a bean post
> > processor?
> >
> > If this doesn't already exit perhaps a new attribute
> > can be added to the
> > bean tag like "load" or "configure". If load=3D"true"
> > then the bean is
> > loaded.
> > In this way Impl1 could be keyed to
> > load=3D"${useImpl1}"
> > and so could all of the Spring managed beans that
> > would be injected into it.
> > Thus, if useImpl1 was false Impl1 and all the
> > objects constructed to support
> > it would never be instantiated.
> >
> > It would also be preferable for references to bean
> > post processor values
> > that used in un-instantiated objects to no longer be
> > necessary. I.E. if
> > Impl1 has someSetter=3D"${someProperty}" and Impl1
> > load=3D"false"
> > then spring should not error if "someProperty" is
> > not provided.
> >
> > Thoughts?
> >
> > Rob
> >
> >
> >
> > __________________________________
> > Yahoo! Mail - PC Magazine Editors' Choice 2005
> > http://mail.yahoo.com
> >
> >
> >
> -------------------------------------------------------
> > SF.Net email is sponsored by:
> > Tame your development challenges with Apache's
> > Geronimo App Server. Download
> > it for free - -and be entered to win a 42" plasma tv
> > or your very own
> > Sony(tm)PSP. Click here to play:
> > http://sourceforge.net/geronimo.php
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
> >
> -------------------------------------------------------
> > SF.Net email is sponsored by:
> > Tame your development challenges with Apache's
> > Geronimo App Server. Download
> > it for free - -and be entered to win a 42" plasma tv
> > or your very own
> > Sony(tm)PSP. Click here to play:
> > http://sourceforge.net/geronimo.php
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] OracleLobHandler on WebSphere 6.0

[Juergen H. <ju...@in...>]

Just changed it into a post-invocation ClassCastException check.
Unfortunately, I haven't any Oracle installation around here, so it would be
great if someone could give this a try. The change to OracleLobHandler is
already committed to CVS HEAD.
 
Juergen
 

  _____  

From: Juergen Hoeller [mailto:ju...@in...] 
Sent: Sunday, October 02, 2005 11:21 PM
To: 'spr...@li...'
Subject: RE: [Springframework-developer] OracleLobHandler on WebSphere 6.0



Actually, the Connection implementation class could be some wrapper whose
name doesn't start with "oracle.jdbc." but which is still assignable to
"oracle.jdbc.OracleConnection"... So I guess we can't use that check.
However, loading the OracleConnection class every time a LOB is accessed
isn't desirable either, even if the Connection handle's class loader would
guarantee proper loading.

Hmm, we could simply not do any explicit check and pass the Connection into
BLOB/CLOB.createTemporary. If a ClassCastException arises, we'll convert
into our nice exception saying "please specify a NativeJdbcExtractor". That
might be a feasible compromise...

Juergen


  _____  

From: Juergen Hoeller [mailto:ju...@in...] 
Sent: Sunday, October 02, 2005 11:15 PM
To: 'spr...@li...'
Subject: Re: [Springframework-developer] OracleLobHandler on WebSphere 6.0


Yes... but I guess checking for the name starting with "oracle.jdbc." would
be fine. It's just about checking whether the passed-in Connection has any
chance of getting accepted by CLOB.createTemporary(con, ...) so we don't
really need a full type check there - just a basic sanity check.
 
Juergen
 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Thomas Risberg
Sent: Sunday, October 02, 2005 11:10 PM
To: spr...@li...
Subject: Re: [Springframework-developer] OracleLobHandler on WebSphere 6.0


We could also use the classloader for the connection to load any classes
used for testing and for reflection - like 

conToUse.getClass().getClassLoader().loadClass(CONNECTION_CLASS_NAME);

Thomas


On Oct 2, 2005, at 4:58 PM, Thomas Risberg wrote:



On Oct 2, 2005, at 4:43 PM, Juergen Hoeller wrote:



So our OracleLobHandler works on the new "oracle.jdbc.Connection" interface,
while WebSphere seems to return an "oracle.jdbc.driver.Connection" that's
not assignable to the "oracle.jdbc.Connection" interface.


The class we test for is:
private static final String CONNECTION_CLASS_NAME =
"oracle.jdbc.OracleConnection";

In my tests any Oracle connection is assignable to this class as long as
they both come from the same classloader.

Seems like the test is the problem here - maybe we should just test for a
class name that starts with "oracle.jdbc"

Thomas

RE: [Springframework-developer] OracleLobHandler on WebSphere 6.0

[Juergen H. <ju...@in...>]

Actually, the Connection implementation class could be some wrapper whose
name doesn't start with "oracle.jdbc." but which is still assignable to
"oracle.jdbc.OracleConnection"... So I guess we can't use that check.
However, loading the OracleConnection class every time a LOB is accessed
isn't desirable either, even if the Connection handle's class loader would
guarantee proper loading.

Hmm, we could simply not do any explicit check and pass the Connection into
BLOB/CLOB.createTemporary. If a ClassCastException arises, we'll convert
into our nice exception saying "please specify a NativeJdbcExtractor". That
might be a feasible compromise...

Juergen


  _____  

From: Juergen Hoeller [mailto:ju...@in...] 
Sent: Sunday, October 02, 2005 11:15 PM
To: 'spr...@li...'
Subject: Re: [Springframework-developer] OracleLobHandler on WebSphere 6.0


Yes... but I guess checking for the name starting with "oracle.jdbc." would
be fine. It's just about checking whether the passed-in Connection has any
chance of getting accepted by CLOB.createTemporary(con, ...) so we don't
really need a full type check there - just a basic sanity check.
 
Juergen
 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Thomas Risberg
Sent: Sunday, October 02, 2005 11:10 PM
To: spr...@li...
Subject: Re: [Springframework-developer] OracleLobHandler on WebSphere 6.0


We could also use the classloader for the connection to load any classes
used for testing and for reflection - like 

conToUse.getClass().getClassLoader().loadClass(CONNECTION_CLASS_NAME);

Thomas


On Oct 2, 2005, at 4:58 PM, Thomas Risberg wrote:



On Oct 2, 2005, at 4:43 PM, Juergen Hoeller wrote:



So our OracleLobHandler works on the new "oracle.jdbc.Connection" interface,
while WebSphere seems to return an "oracle.jdbc.driver.Connection" that's
not assignable to the "oracle.jdbc.Connection" interface.


The class we test for is:
private static final String CONNECTION_CLASS_NAME =
"oracle.jdbc.OracleConnection";

In my tests any Oracle connection is assignable to this class as long as
they both come from the same classloader.

Seems like the test is the problem here - maybe we should just test for a
class name that starts with "oracle.jdbc"

Thomas

Re: [Springframework-developer] OracleLobHandler on WebSphere 6.0

[Juergen H. <ju...@in...>]

Yes... but I guess checking for the name starting with "oracle.jdbc." would
be fine. It's just about checking whether the passed-in Connection has any
chance of getting accepted by CLOB.createTemporary(con, ...) so we don't
really need a full type check there - just a basic sanity check.
 
Juergen
 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Thomas Risberg
Sent: Sunday, October 02, 2005 11:10 PM
To: spr...@li...
Subject: Re: [Springframework-developer] OracleLobHandler on WebSphere 6.0


We could also use the classloader for the connection to load any classes
used for testing and for reflection - like 

conToUse.getClass().getClassLoader().loadClass(CONNECTION_CLASS_NAME);

Thomas


On Oct 2, 2005, at 4:58 PM, Thomas Risberg wrote:



On Oct 2, 2005, at 4:43 PM, Juergen Hoeller wrote:



So our OracleLobHandler works on the new "oracle.jdbc.Connection" interface,
while WebSphere seems to return an "oracle.jdbc.driver.Connection" that's
not assignable to the "oracle.jdbc.Connection" interface.


The class we test for is:
private static final String CONNECTION_CLASS_NAME =
"oracle.jdbc.OracleConnection";

In my tests any Oracle connection is assignable to this class as long as
they both come from the same classloader.

Seems like the test is the problem here - maybe we should just test for a
class name that starts with "oracle.jdbc"

Thomas

Re: [Springframework-developer] OracleLobHandler on WebSphere 6.0

[Juergen H. <ju...@in...>]

Yes, simply relaxing that check might already help. It's still a class
loader issue, but relaxing that check might make our OracleLobHandler work
despite the presence of that CL issue.
 
Juergen
 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Thomas Risberg
Sent: Sunday, October 02, 2005 10:59 PM
To: spr...@li...
Subject: Re: [Springframework-developer] OracleLobHandler on WebSphere 6.0



On Oct 2, 2005, at 4:43 PM, Juergen Hoeller wrote:





So our OracleLobHandler works on the new "oracle.jdbc.Connection" interface,

while WebSphere seems to return an "oracle.jdbc.driver.Connection" that's

not assignable to the "oracle.jdbc.Connection" interface.


The class we test for is:
private static final String CONNECTION_CLASS_NAME =
"oracle.jdbc.OracleConnection";

In my tests any Oracle connection is assignable to this class as long as
they both come from the same classloader.

Seems like the test is the problem here - maybe we should just test for a
class name that starts with "oracle.jdbc"

Thomas

Re: [Springframework-developer] OracleLobHandler on WebSphere 6.0

[Juergen H. <ju...@in...>]

So it's probably indeed a class loader issue... Maybe the reporter had
ojdbc14.jar at both the server and the application level.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Mark St Godard
Sent: Sunday, October 02, 2005 10:33 PM
To: spr...@li...
Subject: Re: [Springframework-developer] OracleLobHandler on WebSphere 6.0





I am running Webpshere 6, with Hibernate 3, Spring 1.2.5 and Oracle 10g....

I also get back a:  oracle.jdbc.driver.T4CConnection

assertTrue(oracle.jdbc.OracleConnection.class.isAssignableFrom(conn.getClass
()));
assertTrue(oracle.jdbc.driver.OracleConnection.class.isAssignableFrom(conn.g
etClass()));

And it looks to be assignable...

Cheers
Mark



                                                                           
             Thomas Risberg                                                
             <thomas.risberg@t                                             
             ridb.com>                                                  To 
             Sent by:                  spr...@li... 
             springframework-d         rceforge.net                        
             eveloper-admin@li                                          cc 
             sts.sourceforge.n                                             
             et                                                    Subject 
                                       Re: [Springframework-developer]     
                                       OracleLobHandler on WebSphere 6.0   
             10/02/2005 03:11                                              
             PM                                                            
                                                                           
                                                                           
             Please respond to                                             
             springframework-d                                             
                 eveloper                                                  
                                                                           
                                                                           




I think the oracle.jdbc.driver.OracleConnection extends
oracle.jdbc.OracleConnection so they should both work.  The connection I get
back from 10g is oracle.jdbc.driver.T4CConnection and it is assignable as
well.  Could this be a class loader issue?

Thomas


On Oct 2, 2005, at 3:20 PM, Duncan Mills wrote:

> Juergen,
> There has been some refactoring in the Oracle JDBC drivers (as of the 
> 10g version) so the correct class is now oracle.jdbc.Connection. 
> oracle.jdbc.driver.Connection is deprecated but should still be 
> supported until version 11 of the database.
> I'm not sure if that's the cause of the problem here but it's probably 
> more than coincidental..
> Duncan
>
> Juergen Hoeller wrote:
>
>
>> We have a report about an issue with Spring's OracleLobHandler on 
>> WebSphere
>> 6.0:
>> http://opensource2.atlassian.com/projects/spring/browse/SPR-1317
>>
>> Our WebSphereNativeJdbcExtractor seems to work, actually. It's rather 
>> that WebSphere returns an object of class "oracle.jdbc.Connection" as 
>> underlying connection there, not an "oracle.jdbc.driver.Connection" - 
>> as expected by our OracleLobHandler, according to the Oracle 9i+ JDBC 
>> API.
>>
>> Could this be caused by a different Oracle driver that WebSphere 
>> uses, at least in that specific scenario? Maybe it uses an older 
>> Oracle driver that doesn't support the "oracle.jdbc.driver" package 
>> yet? Has anybody ever encountered this, no matter whether on 
>> WebSphere or not?
>>
>> It would be great if someone with access to a WebSphere 6.0 + Oracle 
>> installation could give this a try and see whether there's a way to 
>> solve the issue...
>>
>> Juergen
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Power Architecture Resource Center: Free content, downloads, 
>> discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
>> _______________________________________________
>> Springframework-developer mailing list 
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-
>> developer
>>
>>
>
> --
>
> Regards
>
> Duncan Mills
> Senior Principal Product Manager
> Oracle Application Development Tools
>
> Dun...@or...
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, 
> discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] OracleLobHandler on WebSphere 6.0

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

We could also use the classloader for the connection to load any  
classes used for testing and for reflection - like

   conToUse.getClass().getClassLoader().loadClass 
(CONNECTION_CLASS_NAME);

Thomas


On Oct 2, 2005, at 4:58 PM, Thomas Risberg wrote:

>
> On Oct 2, 2005, at 4:43 PM, Juergen Hoeller wrote:
>
>>
>> So our OracleLobHandler works on the new "oracle.jdbc.Connection"  
>> interface,
>> while WebSphere seems to return an "oracle.jdbc.driver.Connection"  
>> that's
>> not assignable to the "oracle.jdbc.Connection" interface.
>
> The class we test for is:
>     private static final String CONNECTION_CLASS_NAME =  
> "oracle.jdbc.OracleConnection";
>
> In my tests any Oracle connection is assignable to this class as  
> long as they both come from the same classloader.
>
> Seems like the test is the problem here - maybe we should just test  
> for a class name that starts with "oracle.jdbc"
>
> Thomas
>
>
>
>