springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Cannot proxy classes lacking no-arg constructor using CGLIB

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

It'd be nice to have it. I can try getting to it, although docs for some 
new features and finishing the 1.5 metadata sample were higher on my list.


jürgen höller [werk3AT] wrote:

>Any insights on that issue? We should address this before 1.1 final, particularly if it's a straightforward change.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
>Gesendet: Mo 30.08.2004 12:23
>An: spr...@li...
>Betreff: [Springframework-developer] Cannot proxy classes lacking no-arg constructor using CGLIB
>
>
>
>Any progress on this issue?
>
>http://opensource.atlassian.com/projects/spring/browse/SPR-285
>
>How much effort would it be to adapt our Cglib2AopProxy accordingly? What Spring release do we plan this for?
>
>Juergen
>  
>

Re: [Springframework-developer] Abstract bean definitions

[Tom T. <tom...@pr...>]

> I've implemented an "abstract" attribute for <bean> tags in XML bean
> definitions. It works as expected in test cases. I've also adapted the
> "baseTxProxy" bean definitions in Petclinic and JPetStore (as introduced
> by Colin) accordingly, marking them as "abstract" rather than
> "lazy-init".

Thanks Juergen!

Maybe support for an "(abstract)" virtual property could also be added
to PropertiesBeanDefinitionReader? We use abstract view definitions
quite often, with a ResourceBundleViewResolver...

Thanks,
Tom.

Re: [Springframework-developer] Cannot proxy classes lacking no-arg constructor using CGLIB

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

Any insights on that issue? We should address this before 1.1 final, =
particularly if it's a straightforward change.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Mo 30.08.2004 12:23
An: spr...@li...
Betreff: [Springframework-developer] Cannot proxy classes lacking no-arg =
constructor using CGLIB



Any progress on this issue?

http://opensource.atlassian.com/projects/spring/browse/SPR-285

How much effort would it be to adapt our Cglib2AopProxy accordingly? =
What Spring release do we plan this for?

Juergen

Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator

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

The only runtime disadvantage of "lookupHomeOnStartup"=3Dfalse and =
"refreshHomeOnConnectFailure"=3Dtrue is that it requires synchronized =
access to the home object. However, that's just very minor overhead.
=20
Additionally, "lookupHomeOnStartup"=3Dfalse does not eagerly validate, =
so misconfiguration will just show on first access rather than on =
startup. As you say, the home is simply not available on web container =
startup with many EJB containers, so it's probably better to accept late =
validation as tradeoff.
=20
I guess it makes sense to use the same defaults for the RMI accessors. =
After all, an RMI server might start later than the web server, or =
restart while the web server stays up.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Mi 01.09.2004 05:43
An: spr...@li...
Betreff: Re: [Springframework-developer] JNDI object caching and =
AbstractJndiLocator



I agree that the renaming makes sense.

I would go for sure with "lookupHomeOnStartup"=3Dfalse as a default. As
for "refreshHomeOnConnectFailure"=3Dtrue, I can't really think of any
negative consequences. Code all looks ok to me, I'll give it a
runthrough tomorrow.


j=FCrgen h=F6ller [werk3AT] wrote:

>How do we proceed with the defaults? Should we make =
"lookupHomeOnStartup"=3Dfalse and "refreshHomeOnConnectFailure"=3Dtrue =
the default?
>
>FYI, I've renamed RmiClientInterceptor's "lookupRmiProxyOnStartup", =
"cacheRmiProxy" and "refreshRmiProxyOnConnectFailure" to =
"lookupStubOnStartup", "cacheStub" and "refreshStubOnConnectFailure", =
respectively. The RMI docs consistently call that thing "stub", so I =
thought we should too, as it also avoids confustion with an AOP proxy as =
provided by RmiProxyFactoryBean.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
>Gesendet: Mo 30.08.2004 15:56
>An: spr...@li...
>Betreff: Re: [Springframework-developer] JNDI object caching and =
AbstractJndiLocator
>
>
>
>I agree that "lookupHomeOnStartup"=3Dfalse would be a sensible default. =
Its only disadvantage, aside from backwards compatibility, is that it =
requires a synchronized block for accessing the home object, which could =
have negative effects in a highly concurrent environment.
>
>The current implementation tries to avoid synchronization wherever it =
can: In particular, "lookupHomeOnStartup"=3Dtrue does not use =
synchronization unless you also specified "refreshHomeOnConnectFailure". =
Same goes for RmiClientInterceptor and JndiRmiClientInterceptor.
>
>That said, I still recommend to specify "lookupHomeOnStartup"=3Dfalse =
and "refreshHomeOnConnectFailure"=3Dtrue in the usual case, to allow for =
both lazy home lookup and automatic refresh/retry if the home became =
stale (for example, after a restart of the target server).
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Sunday, August 29, 2004 5:21 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] JNDI object caching and
>AbstractJndiLocator
>
>
>I think the enhancements are going to help people. From reading your
>mail below (haven't looked at the code yet), it sounds like the
>lookupHomeOnStartup option is on by default. I know that this makes the
>code completely backwards compatible, but IMHO it probably makes more
>sense to have it default to off. In a lot fo containers you had to use
>the lazy-init=3Dtrue setting on the bean previously so you wouldn't =
access
>the ejbs before they were actually loaded, so I think most users will
>want this on by default. Of course, there are some people who will get
>an error message (on bad setup) later rather than sooner with this
>setup, but I think it's going to be less people than get burned by the
>fact their EJBs are not loaded yet.
>
>I'll update the ejbtest integration test/sample at a minimum to test
>some of the new options. I should be able to update the ejb docs to
>mention the new options.
>
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
>=20
>
>>Forget to mention that I've also refactored =
AbstractRemoteSlsbInvokerInterceptor and =
SimpleRemoteSlsbInvokerInterceptor: Subclassing for other proxy fetching =
strategies (as opposed to home fetching strategies) should be =
straightforward now.
>>
>>For example, SimpleRemoteSlsbInvokerInterceptor could be subclassed =
with "getSessionBeanInstance" and "releaseSessionBeanInstance" getting =
overridden to work on a shared SLSB proxy instance, rather than creating =
one for each invocation. The SLSB proxy could be created in an =
"afterPropertiesSet" implementation (calling "newSessionBeanInstance") =
and removed in a "destroy" implementation (calling =
"removeSessionBeanInstance").
>>
>>In total, all defaults should behave just like before, but I believe =
that the new EJB access options (particularly lazy lookup and refresh on =
connect failure) provide significant value for typical usage scenarios. =
And the new RMI options increase the value of standalone RMI as remoting =
strategy, making them a more credible alternative to HTTP-based =
remoting.
>>
>>Colin, what's your view on these changes? We should discuss any issues =
ASAP, to be able to release 1.1 final by the end of the coming week. It =
would also be great to discuss those options briefly in the reference =
manual - do you maybe have the chance to add some brief paragraphs on =
them?
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
>>Gesendet: So 29.08.2004 16:27
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] JNDI object caching and =
AbstractJndiLocator
>>
>>
>>
>>Everything's committed since Friday. Everybody who has the chance, =
please give the new options a try, in particular the new EJB access =
options. I've tested the RMI options quite a bit, but not had a chance =
to play with the EJB options yet.
>>
>>* AbstractSlsbInvokerInterceptor has a new "lookupHomeOnStartup" =
option (alongside the existing "cacheHome"): Turn it off to get lazy =
fetching of the EJB home, on first access, caching the home from then =
on. The interceptor respectively proxy bean can still be initialized =
eagerly, so there's no need to mark its bean definition as "lazy-init".
>>
>>* AbstractRemoteSlsbInvokerInterceptor has a new =
"refreshHomeOnConnectFailure" option: Turn it on to automatically =
refresh the home and retry if a call resulted in a =
java.rmi.ConnectException. This should work without side effects, as =
ConnectException should just be thrown if no socket connection to the =
target server could be established: Retrying the call with a fresh EJB =
home should be a safe operation in that case. The default is off, =
though.
>>
>>* RmiClientInterceptor and JndiRmiClientInterceptor have analogous =
"lookupRmiProxyOnStartup", "cacheRmiProxy" and =
"refreshRmiProxyOnConnectFailure" options. By default, the first two =
options are on and the latter is off. Those can in principle be combined =
in any way, as they are independent to a large degree. The refresh =
option behaves similarly to with EJB homes: It refreshes and retries on =
java.rmi.ConnectException.
>>
>>So there are two main new features for EJB and RMI: lazy =
initialization of a cached EJB home without resorting to defining the =
bean as "lazy-init", and refreshing the EJB home object respectively RMI =
proxy if it became stale. The latter allows for hot restarts of the EJB =
respectively RMI server without restarting the client, no matter whether =
the EJB home supports auto-failover itself.
>>
>>This brings the EJB and RMI support to the same convenience level as =
the HTTP-based protocols (Hessian, Burlap, HTTP invoker): Starting up =
the remote server later than the client or restarting the remote server =
without restarting the client does not pose a problem for HTTP-based =
remoting in the first place, as there is no proxy holding a connection =
that could become stale there. Therefore, the above options are not =
necessary for the HTTP remoting support in the first place.
>>
>>Juergen
>>
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
>>Gesendet: Mi 25.08.2004 21:23
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] JNDI object caching and =
AbstractJndiLocator
>>
>>
>>
>>I've basically finished the reworked proxy fetching stuff: =
RmiClientInterceptor, JndiRmiClientInterceptor and =
AbstractSlsbInvokerInterceptor all support the four fetching strategies =
I've mentioned, through two flags (look proxy up on startup, cache =
proxy). As those accessors are capable of refetching the proxy now, we =
can also easily allow for further strategies, for example to check a =
proxy and refetch if it is broken (with custom check implementation).
>>
>>I've also added a JndiObjectTargetSource that can be used to refetch a =
JNDI object for each call. It supports two analogous flags, so the =
actual fetching strategy can be customized. I've tested this with an =
OpenJMS ConnectionFactory: By defining it as ProxyFactoryBean plus =
JndiObjectTargetSource instead of a JndiObjetcFactoryBean, each =
createConnection call can trigger a fresh JNDI lookup to make sure that =
the ConnectionFactory reference is valid.
>>
>>While refetching of RMI proxies and JNDI objects for each operation of =
course represents a significant overhead, it's not too bad if the =
respective objects are rarely used. I still rather consider this as =
development feature, though, to allow restarting of remote processes =
while keeping the clients alive. Lazily initializing the references is a =
good feature for production too: The remote processes do not have to be =
alive when the clients start up then.
>>
>>I'll commit all of that stuff tomorrow, after having gone through it =
in terms of documentation etc. I'll also put some further thought into =
custom refetching strategies, providing appropriate hooks for =
subclasses. In the future, we might introduce an appropriate strategy =
interface for that.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag =
von Colin Sampaleanu
>>Gesendet: Mi 25.08.2004 15:08
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] JNDI object caching and =
AbstractJndiLocator
>>
>>
>>
>>j=FCrgen h=F6ller [werk3AT] wrote:
>>
>>
>>
>>  =20
>>
>>>One further thing: JndiObjectFactoryBean currently returns its =
located object as-is for the entire lifetime of the client application: =
If the located object becomes broken at some point of time (which can =
happen, for example, to an SFSB home or a JMS Destination), clients will =
carry an unusable reference from then on. Our remoting accessors, on the =
other hand, expose the same remote service proxy all the time, being =
able to delegate calls to changing backend stubs (for example, refetched =
SLSB homes).
>>>
>>>So what we could do is add an analogous "cacheJndiObject" flag to =
JndiObjectFactoryBean, with the option to turn it off for refetching on =
every access - while clients still receive a single reference that does =
not break. In the latter case, we'd have to expose a proxy that =
implements the same interfaces as the JNDI object, delegating all calls =
to the current backend object. This could be useful for SFSB homes and =
JMS Destinations, particularly during development.
>>>
>>>Of course, the choice between looking up once and refetching on every =
access is a bit simplistic. If we could determine that a reference to a =
JNDI object or RMI proxy is broken, we could apply a more sophisticated =
strategy, just refetching if actually necessary. Unfortunately, I don't =
see a reliable way to achieve this for generic JNDI objects. Is there =
maybe a specific way for EJB homes, JMS Destinations, RMI proxies, =
respectively?
>>>
>>>
>>>=20
>>>
>>>    =20
>>>
>>I agree that this is the ideal. When you are working with stateless
>>objects, the best scenario is one where you only do the lookups again
>>when absolutely necessary, i.e. the object is broken. But 'broken' =
means
>>different things for the different kinds of objects. It may even be
>>application-specific.
>>
>>
>>
>>  =20
>>
>>>BTW, hot refetching of JNDI objects also makes sense for local SLSBs, =
as requested by a user some time ago: Local SLSBs can be hot-redeployed =
too, shutting down the current EJB class loader and starting up a fresh =
one. So the "cacheHome" flag on our SLSB accessors makes sense for local =
SLSBs too, particularly during development. Likewise, a =
"cacheJndiObject" flag on JndiObjectFactoryBean might make sense for a =
local object too, if the server supports hot-redeploying the respective =
target object.
>>>
>>>Juergen
>>>    =20
>>>




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator

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

I agree that the renaming makes sense.

I would go for sure with "lookupHomeOnStartup"=false as a default. As 
for "refreshHomeOnConnectFailure"=true, I can't really think of any 
negative consequences. Code all looks ok to me, I'll give it a 
runthrough tomorrow.


jürgen höller [werk3AT] wrote:

>How do we proceed with the defaults? Should we make "lookupHomeOnStartup"=false and "refreshHomeOnConnectFailure"=true the default?
> 
>FYI, I've renamed RmiClientInterceptor's "lookupRmiProxyOnStartup", "cacheRmiProxy" and "refreshRmiProxyOnConnectFailure" to "lookupStubOnStartup", "cacheStub" and "refreshStubOnConnectFailure", respectively. The RMI docs consistently call that thing "stub", so I thought we should too, as it also avoids confustion with an AOP proxy as provided by RmiProxyFactoryBean.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
>Gesendet: Mo 30.08.2004 15:56
>An: spr...@li...
>Betreff: Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator
>
>
>
>I agree that "lookupHomeOnStartup"=false would be a sensible default. Its only disadvantage, aside from backwards compatibility, is that it requires a synchronized block for accessing the home object, which could have negative effects in a highly concurrent environment.
>
>The current implementation tries to avoid synchronization wherever it can: In particular, "lookupHomeOnStartup"=true does not use synchronization unless you also specified "refreshHomeOnConnectFailure". Same goes for RmiClientInterceptor and JndiRmiClientInterceptor.
>
>That said, I still recommend to specify "lookupHomeOnStartup"=false and "refreshHomeOnConnectFailure"=true in the usual case, to allow for both lazy home lookup and automatic refresh/retry if the home became stale (for example, after a restart of the target server).
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Sunday, August 29, 2004 5:21 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] JNDI object caching and
>AbstractJndiLocator
>
>
>I think the enhancements are going to help people. From reading your
>mail below (haven't looked at the code yet), it sounds like the
>lookupHomeOnStartup option is on by default. I know that this makes the
>code completely backwards compatible, but IMHO it probably makes more
>sense to have it default to off. In a lot fo containers you had to use
>the lazy-init=true setting on the bean previously so you wouldn't access
>the ejbs before they were actually loaded, so I think most users will
>want this on by default. Of course, there are some people who will get
>an error message (on bad setup) later rather than sooner with this
>setup, but I think it's going to be less people than get burned by the
>fact their EJBs are not loaded yet.
>
>I'll update the ejbtest integration test/sample at a minimum to test
>some of the new options. I should be able to update the ejb docs to
>mention the new options.
>
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Forget to mention that I've also refactored AbstractRemoteSlsbInvokerInterceptor and SimpleRemoteSlsbInvokerInterceptor: Subclassing for other proxy fetching strategies (as opposed to home fetching strategies) should be straightforward now.
>>
>>For example, SimpleRemoteSlsbInvokerInterceptor could be subclassed with "getSessionBeanInstance" and "releaseSessionBeanInstance" getting overridden to work on a shared SLSB proxy instance, rather than creating one for each invocation. The SLSB proxy could be created in an "afterPropertiesSet" implementation (calling "newSessionBeanInstance") and removed in a "destroy" implementation (calling "removeSessionBeanInstance").
>>
>>In total, all defaults should behave just like before, but I believe that the new EJB access options (particularly lazy lookup and refresh on connect failure) provide significant value for typical usage scenarios. And the new RMI options increase the value of standalone RMI as remoting strategy, making them a more credible alternative to HTTP-based remoting.
>>
>>Colin, what's your view on these changes? We should discuss any issues ASAP, to be able to release 1.1 final by the end of the coming week. It would also be great to discuss those options briefly in the reference manual - do you maybe have the chance to add some brief paragraphs on them?
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
>>Gesendet: So 29.08.2004 16:27
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator
>>
>>
>>
>>Everything's committed since Friday. Everybody who has the chance, please give the new options a try, in particular the new EJB access options. I've tested the RMI options quite a bit, but not had a chance to play with the EJB options yet.
>>
>>* AbstractSlsbInvokerInterceptor has a new "lookupHomeOnStartup" option (alongside the existing "cacheHome"): Turn it off to get lazy fetching of the EJB home, on first access, caching the home from then on. The interceptor respectively proxy bean can still be initialized eagerly, so there's no need to mark its bean definition as "lazy-init".
>>
>>* AbstractRemoteSlsbInvokerInterceptor has a new "refreshHomeOnConnectFailure" option: Turn it on to automatically refresh the home and retry if a call resulted in a java.rmi.ConnectException. This should work without side effects, as ConnectException should just be thrown if no socket connection to the target server could be established: Retrying the call with a fresh EJB home should be a safe operation in that case. The default is off, though.
>>
>>* RmiClientInterceptor and JndiRmiClientInterceptor have analogous "lookupRmiProxyOnStartup", "cacheRmiProxy" and "refreshRmiProxyOnConnectFailure" options. By default, the first two options are on and the latter is off. Those can in principle be combined in any way, as they are independent to a large degree. The refresh option behaves similarly to with EJB homes: It refreshes and retries on java.rmi.ConnectException.
>>
>>So there are two main new features for EJB and RMI: lazy initialization of a cached EJB home without resorting to defining the bean as "lazy-init", and refreshing the EJB home object respectively RMI proxy if it became stale. The latter allows for hot restarts of the EJB respectively RMI server without restarting the client, no matter whether the EJB home supports auto-failover itself.
>>
>>This brings the EJB and RMI support to the same convenience level as the HTTP-based protocols (Hessian, Burlap, HTTP invoker): Starting up the remote server later than the client or restarting the remote server without restarting the client does not pose a problem for HTTP-based remoting in the first place, as there is no proxy holding a connection that could become stale there. Therefore, the above options are not necessary for the HTTP remoting support in the first place.
>>
>>Juergen
>>
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
>>Gesendet: Mi 25.08.2004 21:23
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator
>>
>>
>>
>>I've basically finished the reworked proxy fetching stuff: RmiClientInterceptor, JndiRmiClientInterceptor and AbstractSlsbInvokerInterceptor all support the four fetching strategies I've mentioned, through two flags (look proxy up on startup, cache proxy). As those accessors are capable of refetching the proxy now, we can also easily allow for further strategies, for example to check a proxy and refetch if it is broken (with custom check implementation).
>>
>>I've also added a JndiObjectTargetSource that can be used to refetch a JNDI object for each call. It supports two analogous flags, so the actual fetching strategy can be customized. I've tested this with an OpenJMS ConnectionFactory: By defining it as ProxyFactoryBean plus JndiObjectTargetSource instead of a JndiObjetcFactoryBean, each createConnection call can trigger a fresh JNDI lookup to make sure that the ConnectionFactory reference is valid.
>>
>>While refetching of RMI proxies and JNDI objects for each operation of course represents a significant overhead, it's not too bad if the respective objects are rarely used. I still rather consider this as development feature, though, to allow restarting of remote processes while keeping the clients alive. Lazily initializing the references is a good feature for production too: The remote processes do not have to be alive when the clients start up then.
>>
>>I'll commit all of that stuff tomorrow, after having gone through it in terms of documentation etc. I'll also put some further thought into custom refetching strategies, providing appropriate hooks for subclasses. In the future, we might introduce an appropriate strategy interface for that.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von Colin Sampaleanu
>>Gesendet: Mi 25.08.2004 15:08
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator
>>
>>
>>
>>jürgen höller [werk3AT] wrote:
>>
>>
>>
>>    
>>
>>>One further thing: JndiObjectFactoryBean currently returns its located object as-is for the entire lifetime of the client application: If the located object becomes broken at some point of time (which can happen, for example, to an SFSB home or a JMS Destination), clients will carry an unusable reference from then on. Our remoting accessors, on the other hand, expose the same remote service proxy all the time, being able to delegate calls to changing backend stubs (for example, refetched SLSB homes).
>>>
>>>So what we could do is add an analogous "cacheJndiObject" flag to JndiObjectFactoryBean, with the option to turn it off for refetching on every access - while clients still receive a single reference that does not break. In the latter case, we'd have to expose a proxy that implements the same interfaces as the JNDI object, delegating all calls to the current backend object. This could be useful for SFSB homes and JMS Destinations, particularly during development.
>>>
>>>Of course, the choice between looking up once and refetching on every access is a bit simplistic. If we could determine that a reference to a JNDI object or RMI proxy is broken, we could apply a more sophisticated strategy, just refetching if actually necessary. Unfortunately, I don't see a reliable way to achieve this for generic JNDI objects. Is there maybe a specific way for EJB homes, JMS Destinations, RMI proxies, respectively?
>>>
>>>
>>>  
>>>
>>>      
>>>
>>I agree that this is the ideal. When you are working with stateless
>>objects, the best scenario is one where you only do the lookups again
>>when absolutely necessary, i.e. the object is broken. But 'broken' means
>>different things for the different kinds of objects. It may even be
>>application-specific.
>>
>>
>>
>>    
>>
>>>BTW, hot refetching of JNDI objects also makes sense for local SLSBs, as requested by a user some time ago: Local SLSBs can be hot-redeployed too, shutting down the current EJB class loader and starting up a fresh one. So the "cacheHome" flag on our SLSB accessors makes sense for local SLSBs too, particularly during development. Likewise, a "cacheJndiObject" flag on JndiObjectFactoryBean might make sense for a local object too, if the server supports hot-redeploying the respective target object.
>>>
>>>Juergen
>>>      
>>>

[Springframework-developer] Portlets module and Spring MVC

[Nick L. <nl...@es...>]

Hi,

Over the last couple of weeks I've spent some time (on & off) doing stuff
with the Spring Portlets sandbox module. I've read
<http://opensource.atlassian.com/confluence/spring/display/JSR168/SpringPort
let+module+design+discussion> and a fair amount of the code.

I'm finding the Model-Controller part quite nice, and adequately flexible.
The problem I'm running into is the View part.

I would like to use the Spring taglibs with the portlet framework, and I've
done some work to try and get this happening. My impression from the design
discussion referenced above is that this is the direction it was heading in.

I've got it to the point that I believe is known as the 'infamous "Could not
find Errors instance"'
(http://article.gmane.org/gmane.comp.java.springframework.user/3863).
Unfortunately since my controller is a PortletController, the solution isn't
as straight forward as it should be. Right now I'm trying to fake up a error
instance manually, and then figure out a better solution when I understand
it better (Any pointers for some code to do this would be appreciated!).

Is this the best approach? As a general strategy am I better off altering
the portlet framework to do things like making a default ThemeResolver
available etc, or should I be looking at modifying the taglibs to work
without that stuff?

Is it a realistic goal to get these taglibs working in the portlet
environment at all?

Nick

Re: [Springframework-developer] JNDI object caching and AbstractJndiLocator

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

How do we proceed with the defaults? Should we make =
"lookupHomeOnStartup"=3Dfalse and "refreshHomeOnConnectFailure"=3Dtrue =
the default?
=20
FYI, I've renamed RmiClientInterceptor's "lookupRmiProxyOnStartup", =
"cacheRmiProxy" and "refreshRmiProxyOnConnectFailure" to =
"lookupStubOnStartup", "cacheStub" and "refreshStubOnConnectFailure", =
respectively. The RMI docs consistently call that thing "stub", so I =
thought we should too, as it also avoids confustion with an AOP proxy as =
provided by RmiProxyFactoryBean.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Mo 30.08.2004 15:56
An: spr...@li...
Betreff: Re: [Springframework-developer] JNDI object caching and =
AbstractJndiLocator



I agree that "lookupHomeOnStartup"=3Dfalse would be a sensible default. =
Its only disadvantage, aside from backwards compatibility, is that it =
requires a synchronized block for accessing the home object, which could =
have negative effects in a highly concurrent environment.

The current implementation tries to avoid synchronization wherever it =
can: In particular, "lookupHomeOnStartup"=3Dtrue does not use =
synchronization unless you also specified "refreshHomeOnConnectFailure". =
Same goes for RmiClientInterceptor and JndiRmiClientInterceptor.

That said, I still recommend to specify "lookupHomeOnStartup"=3Dfalse =
and "refreshHomeOnConnectFailure"=3Dtrue in the usual case, to allow for =
both lazy home lookup and automatic refresh/retry if the home became =
stale (for example, after a restart of the target server).

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Sunday, August 29, 2004 5:21 PM
To: spr...@li...
Subject: Re: [Springframework-developer] JNDI object caching and
AbstractJndiLocator


I think the enhancements are going to help people. From reading your
mail below (haven't looked at the code yet), it sounds like the
lookupHomeOnStartup option is on by default. I know that this makes the
code completely backwards compatible, but IMHO it probably makes more
sense to have it default to off. In a lot fo containers you had to use
the lazy-init=3Dtrue setting on the bean previously so you wouldn't =
access
the ejbs before they were actually loaded, so I think most users will
want this on by default. Of course, there are some people who will get
an error message (on bad setup) later rather than sooner with this
setup, but I think it's going to be less people than get burned by the
fact their EJBs are not loaded yet.

I'll update the ejbtest integration test/sample at a minimum to test
some of the new options. I should be able to update the ejb docs to
mention the new options.


j=FCrgen h=F6ller [werk3AT] wrote:

>Forget to mention that I've also refactored =
AbstractRemoteSlsbInvokerInterceptor and =
SimpleRemoteSlsbInvokerInterceptor: Subclassing for other proxy fetching =
strategies (as opposed to home fetching strategies) should be =
straightforward now.
>
>For example, SimpleRemoteSlsbInvokerInterceptor could be subclassed =
with "getSessionBeanInstance" and "releaseSessionBeanInstance" getting =
overridden to work on a shared SLSB proxy instance, rather than creating =
one for each invocation. The SLSB proxy could be created in an =
"afterPropertiesSet" implementation (calling "newSessionBeanInstance") =
and removed in a "destroy" implementation (calling =
"removeSessionBeanInstance").
>
>In total, all defaults should behave just like before, but I believe =
that the new EJB access options (particularly lazy lookup and refresh on =
connect failure) provide significant value for typical usage scenarios. =
And the new RMI options increase the value of standalone RMI as remoting =
strategy, making them a more credible alternative to HTTP-based =
remoting.
>
>Colin, what's your view on these changes? We should discuss any issues =
ASAP, to be able to release 1.1 final by the end of the coming week. It =
would also be great to discuss those options briefly in the reference =
manual - do you maybe have the chance to add some brief paragraphs on =
them?
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
>Gesendet: So 29.08.2004 16:27
>An: spr...@li...
>Betreff: Re: [Springframework-developer] JNDI object caching and =
AbstractJndiLocator
>
>
>
>Everything's committed since Friday. Everybody who has the chance, =
please give the new options a try, in particular the new EJB access =
options. I've tested the RMI options quite a bit, but not had a chance =
to play with the EJB options yet.
>
>* AbstractSlsbInvokerInterceptor has a new "lookupHomeOnStartup" option =
(alongside the existing "cacheHome"): Turn it off to get lazy fetching =
of the EJB home, on first access, caching the home from then on. The =
interceptor respectively proxy bean can still be initialized eagerly, so =
there's no need to mark its bean definition as "lazy-init".
>
>* AbstractRemoteSlsbInvokerInterceptor has a new =
"refreshHomeOnConnectFailure" option: Turn it on to automatically =
refresh the home and retry if a call resulted in a =
java.rmi.ConnectException. This should work without side effects, as =
ConnectException should just be thrown if no socket connection to the =
target server could be established: Retrying the call with a fresh EJB =
home should be a safe operation in that case. The default is off, =
though.
>
>* RmiClientInterceptor and JndiRmiClientInterceptor have analogous =
"lookupRmiProxyOnStartup", "cacheRmiProxy" and =
"refreshRmiProxyOnConnectFailure" options. By default, the first two =
options are on and the latter is off. Those can in principle be combined =
in any way, as they are independent to a large degree. The refresh =
option behaves similarly to with EJB homes: It refreshes and retries on =
java.rmi.ConnectException.
>
>So there are two main new features for EJB and RMI: lazy initialization =
of a cached EJB home without resorting to defining the bean as =
"lazy-init", and refreshing the EJB home object respectively RMI proxy =
if it became stale. The latter allows for hot restarts of the EJB =
respectively RMI server without restarting the client, no matter whether =
the EJB home supports auto-failover itself.
>
>This brings the EJB and RMI support to the same convenience level as =
the HTTP-based protocols (Hessian, Burlap, HTTP invoker): Starting up =
the remote server later than the client or restarting the remote server =
without restarting the client does not pose a problem for HTTP-based =
remoting in the first place, as there is no proxy holding a connection =
that could become stale there. Therefore, the above options are not =
necessary for the HTTP remoting support in the first place.
>
>Juergen
>
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
>Gesendet: Mi 25.08.2004 21:23
>An: spr...@li...
>Betreff: Re: [Springframework-developer] JNDI object caching and =
AbstractJndiLocator
>
>
>
>I've basically finished the reworked proxy fetching stuff: =
RmiClientInterceptor, JndiRmiClientInterceptor and =
AbstractSlsbInvokerInterceptor all support the four fetching strategies =
I've mentioned, through two flags (look proxy up on startup, cache =
proxy). As those accessors are capable of refetching the proxy now, we =
can also easily allow for further strategies, for example to check a =
proxy and refetch if it is broken (with custom check implementation).
>
>I've also added a JndiObjectTargetSource that can be used to refetch a =
JNDI object for each call. It supports two analogous flags, so the =
actual fetching strategy can be customized. I've tested this with an =
OpenJMS ConnectionFactory: By defining it as ProxyFactoryBean plus =
JndiObjectTargetSource instead of a JndiObjetcFactoryBean, each =
createConnection call can trigger a fresh JNDI lookup to make sure that =
the ConnectionFactory reference is valid.
>
>While refetching of RMI proxies and JNDI objects for each operation of =
course represents a significant overhead, it's not too bad if the =
respective objects are rarely used. I still rather consider this as =
development feature, though, to allow restarting of remote processes =
while keeping the clients alive. Lazily initializing the references is a =
good feature for production too: The remote processes do not have to be =
alive when the clients start up then.
>
>I'll commit all of that stuff tomorrow, after having gone through it in =
terms of documentation etc. I'll also put some further thought into =
custom refetching strategies, providing appropriate hooks for =
subclasses. In the future, we might introduce an appropriate strategy =
interface for that.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von Colin Sampaleanu
>Gesendet: Mi 25.08.2004 15:08
>An: spr...@li...
>Betreff: Re: [Springframework-developer] JNDI object caching and =
AbstractJndiLocator
>
>
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
>=20
>
>>One further thing: JndiObjectFactoryBean currently returns its located =
object as-is for the entire lifetime of the client application: If the =
located object becomes broken at some point of time (which can happen, =
for example, to an SFSB home or a JMS Destination), clients will carry =
an unusable reference from then on. Our remoting accessors, on the other =
hand, expose the same remote service proxy all the time, being able to =
delegate calls to changing backend stubs (for example, refetched SLSB =
homes).
>>
>>So what we could do is add an analogous "cacheJndiObject" flag to =
JndiObjectFactoryBean, with the option to turn it off for refetching on =
every access - while clients still receive a single reference that does =
not break. In the latter case, we'd have to expose a proxy that =
implements the same interfaces as the JNDI object, delegating all calls =
to the current backend object. This could be useful for SFSB homes and =
JMS Destinations, particularly during development.
>>
>>Of course, the choice between looking up once and refetching on every =
access is a bit simplistic. If we could determine that a reference to a =
JNDI object or RMI proxy is broken, we could apply a more sophisticated =
strategy, just refetching if actually necessary. Unfortunately, I don't =
see a reliable way to achieve this for generic JNDI objects. Is there =
maybe a specific way for EJB homes, JMS Destinations, RMI proxies, =
respectively?
>>
>>
>>  =20
>>
>I agree that this is the ideal. When you are working with stateless
>objects, the best scenario is one where you only do the lookups again
>when absolutely necessary, i.e. the object is broken. But 'broken' =
means
>different things for the different kinds of objects. It may even be
>application-specific.
>
>=20
>
>>BTW, hot refetching of JNDI objects also makes sense for local SLSBs, =
as requested by a user some time ago: Local SLSBs can be hot-redeployed =
too, shutting down the current EJB class loader and starting up a fresh =
one. So the "cacheHome" flag on our SLSB accessors makes sense for local =
SLSBs too, particularly during development. Likewise, a =
"cacheJndiObject" flag on JndiObjectFactoryBean might make sense for a =
local object too, if the server supports hot-redeploying the respective =
target object.
>>
>>Juergen
>>  =20
>>




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] spring build.91 Build Successful

[<al...@jt...>]

<html><head>
<style>
.white { color:#FFFFFF }.index { background-color:#FFFFFF }.index-passed { =
color:#004400 }.index-failed { color:#FF0000; font-weight:bold }.index-head=
er { font-weight:bold }.link { font-family:arial,helvetica,sans-serif; font=
-size:10pt; color:#FFFFFF; text-decoration:none; }.tab-table { margin: 0em =
0em 0.5em 0em; }.tabs { font-family:arial,helvetica,sans-serif; font-size:8=
pt; color:#000000; font-weight:bold; padding: 0em 2em; background-color:#EE=
EEEE; }.tabs-link { color:#000000; text-decoration:none; }.tabs-link:visite=
d { color:#000000; text-decoration:none; }.tabs-selected { font-family:aria=
l,helvetica,sans-serif; font-size:8pt; color:#000000; font-weight:bold; pad=
ding: 0em 2em; }.tabs-selected { border: inset; }.header-title { font-famil=
y:arial,helvetica,sans-serif; font-size:12pt; color:#000000; font-weight:bo=
ld; }.header-label { font-weight:bold; }.header-data { font-family:arial,he=
lvetica,sans-serif; font-size:10pt; color:#000000; }.modifications-data { f=
ont-family:arial,helvetica,sans-serif; font-size:8pt; color:#000000; }.modi=
fications-sectionheader { background-color:#000066; font-family:arial,helve=
tica,sans-serif; font-size:10pt; color:#FFFFFF; }.modifications-oddrow { ba=
ckground-color:#CCCCCC }.modifications-evenrow { background-color:#FFFFCC }=
.changelists-oddrow { background-color:#CCCCCC }.changelists-evenrow { back=
ground-color:#FFFFCC }.changelists-file-spacer { background-color:#FFFFFF }=
.changelists-file-evenrow { background-color:#EEEEEE }.changelists-file-odd=
row { background-color:#FFFFEE }.changelists-file-header { background-color=
:#666666; font-family:arial,helvetica,sans-serif; font-size:8pt; color:#FFF=
FFF; }.compile-data { font-family:arial,helvetica,sans-serif; font-size:8pt=
; color:#000000; }.compile-error-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#FF0000; }.compile-warn-data { font-family:arial,=
helvetica,sans-serif; font-size:8pt; color:#CC9900; }.compile-sectionheader=
 { background-color:#000066; font-family:arial,helvetica,sans-serif; font-s=
ize:10pt; color:#FFFFFF; }.distributables-data { font-family:arial,helvetic=
a,sans-serif; font-size:8pt; color:#000000; }.distributables-sectionheader =
{ background-color:#000066; font-family:arial,helvetica,sans-serif; font-si=
ze:10pt; color:#FFFFFF; }.distributables-oddrow { background-color:#CCCCCC =
}.unittests-sectionheader { background-color:#000066; font-family:arial,hel=
vetica,sans-serif; font-size:10pt; color:#FFFFFF; }.unittests-oddrow { back=
ground-color:#CCCCCC }.unittests-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#000000; }.unittests-error { font-family:arial,he=
lvetica,sans-serif; font-size:8pt; color:#FF0000; }.checkstyle-oddrow { bac=
kground-color:#CCCCCC }.checkstyle-data { font-family:arial,helvetica,sans-=
serif; font-size:8pt; color:#000000; }.checkstyle-sectionheader { backgroun=
d-color:#000066; font-family:arial,helvetica,sans-serif; font-size:10pt; co=
lor:#FFFFFF; }
</style>
</head><body>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"header-title">BUILD COMPLETE&nbsp;-&nbsp;     =
               build.91</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build:&nbsp;</span>09/01/2004 00:15:46</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>13 minutes 26 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed:&nbsp;</span>08/31/2004 19:06:06</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try:&nbsp;</span>Added doco for the MimeMessageHelper and the addInline and=
 addAttachment methods</td></tr></table><p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"/><p>
<p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"><tr><td class=
=3D"compile-sectionheader">                        &nbsp;Errors/Warnings: (=
6)                    </td></tr><tr><td><pre class=3D"compile-error-data">N=
ote: Some input files use or override a deprecated API.<br class=3D"none"/>=
Note: Recompile with -deprecation for details.Note: /jteam/build/checkout/s=
pring/spring/mock/org/springframework/mock/web/MockHttpSession.java uses or=
 overrides a deprecated API.<br class=3D"none"/>Note: Recompile with -depre=
cation for details.<br class=3D"none"/>Note: Some input files use or overri=
de a deprecated API.<br class=3D"none"/>Note: Recompile with -deprecation f=
or details.<br class=3D"none"/></pre></td></tr></table><p>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"unittests-sectionheader">       =
            &nbsp;Unit Tests: (1470)                </td></tr><tr><td><tabl=
e width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"c=
enter"><tr><td class=3D"unittests-data">                failure            =
</td><td width=3D"40%" class=3D"unittests-data">testHomePage</td><td width=
=3D"40%" class=3D"unittests-data">org.springframework.apptests.buildtest.Al=
lTests</td></tr></table></td></tr><tr></tr><tr><td colspan=3D"2">&nbsp;</td=
></tr><tr><td colspan=3D"4" class=3D"unittests-sectionheader">             =
       &nbsp;Unit Test Error Details:&nbsp;(1)                </td></tr><tr=
><td class=3D"unittests-data" colspan=3D"2">                Test:&nbsp;test=
HomePage</td></tr><tr><td class=3D"unittests-data" colspan=3D"2">          =
      Class:&nbsp;org.springframework.apptests.buildtest.AllTests</td></tr>=
<tr><td class=3D"unittests-data" colspan=3D"2">                Type: junit.=
framework.AssertionFailedError</td></tr><tr><td class=3D"unittests-data" co=
lspan=3D"2">                Message: Exception while testing URL http://loc=
alhost:13084/buildtest:java.io.IOException</td></tr><tr><td class=3D"unitte=
sts-error" colspan=3D"2"><pre>junit.framework.AssertionFailedError: Excepti=
on while testing URL http://localhost:13084/buildtest:java.io.IOException<b=
r>=09at org.springframework.apptests.buildtest.AllTests.testHomePage(Unknow=
n Source)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Meth=
od)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess=
orImpl.java:39)<br>=09at sun.reflect.DelegatingMethodAccessorImpl.invoke(De=
legatingMethodAccessorImpl.java:25)<br></pre></td></tr><tr><td colspan=3D"2=
">&nbsp;</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"modifications-sectionheader">   =
                 &nbsp;Modifications since last build:&nbsp;               =
     (69)                </td></tr><tr class=3D"modifications-evenrow"><td =
class=3D"modifications-data">modified</td><td class=3D"modifications-data">=
aarendsen</td><td class=3D"modifications-data">docs/reference/src/mail.xml<=
/td><td class=3D"modifications-data">Added doco for the MimeMessageHelper a=
nd the addInline and addAttachment methods</td></tr><tr class=3D"modificati=
ons-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"modi=
fications-data">jhoeller</td><td class=3D"modifications-data">/changelog.tx=
t</td><td class=3D"modifications-data">StatementCreatorUtils, PersistenceBr=
okerTemplate, MessageTag</td></tr><tr class=3D"modifications-evenrow"><td c=
lass=3D"modifications-data">added</td><td class=3D"modifications-data">jhoe=
ller</td><td class=3D"modifications-data">test/org/springframework/jdbc/cor=
e/StatementCreatorUtilsTests.java</td><td class=3D"modifications-data">adde=
d auto-conversion of java.util.Calendar to java.sql.Date/Time/Timestamp (fo=
r SQL types DATE/TIME/TIMESTAMP), added auto-conversion of java.util.Date a=
nd java.util.Calendar to java.sql.Date (in case of an unknown SQL type)</td=
></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">m=
odified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modi=
fications-data">src/org/springframework/jdbc/core/StatementCreatorUtils.jav=
a</td><td class=3D"modifications-data">added auto-conversion of java.util.C=
alendar to java.sql.Date/Time/Timestamp (for SQL types DATE/TIME/TIMESTAMP)=
, added auto-conversion of java.util.Date and java.util.Calendar to java.sq=
l.Date (in case of an unknown SQL type)</td></tr><tr class=3D"modifications=
-evenrow"><td class=3D"modifications-data">modified</td><td class=3D"modifi=
cations-data">jhoeller</td><td class=3D"modifications-data">test/org/spring=
framework/web/servlet/tags/MessageTestSuite.java</td><td class=3D"modificat=
ions-data">fixed MessageTag to write "null" to the JspWriter in case of a n=
ull value as message</td></tr><tr class=3D"modifications-oddrow"><td class=
=3D"modifications-data">modified</td><td class=3D"modifications-data">jhoel=
ler</td><td class=3D"modifications-data">src/org/springframework/web/servle=
t/tags/MessageTag.java</td><td class=3D"modifications-data">fixed MessageTa=
g to write "null" to the JspWriter in case of a null value as message</td><=
/tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-data">mo=
dified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modif=
ications-data">/changelog.txt</td><td class=3D"modifications-data">"abstrac=
t" bean definitions, "getNrOfXxx" -&gt; "getXxxCount"</td></tr><tr class=3D=
"modifications-oddrow"><td class=3D"modifications-data">modified</td><td cl=
ass=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">sa=
mples/countries/war/WEB-INF/views/jsp/countries/main/home.jsp</td><td class=
=3D"modifications-data">deprecated PagedListHolder's "getNrOfPages" in favo=
r of "getPageCount"</td></tr><tr class=3D"modifications-evenrow"><td class=
=3D"modifications-data">modified</td><td class=3D"modifications-data">jhoel=
ler</td><td class=3D"modifications-data">src/org/springframework/web/servle=
t/mvc/AbstractWizardFormController.java</td><td class=3D"modifications-data=
">deprecated "getNrOfPages" in favor of "getPageCount"</td></tr><tr class=
=3D"modifications-oddrow"><td class=3D"modifications-data">modified</td><td=
 class=3D"modifications-data">jhoeller</td><td class=3D"modifications-data"=
>src/org/springframework/beans/support/PagedListHolder.java</td><td class=
=3D"modifications-data">deprecated "getNrOfPages" in favor of "getPageCount=
"</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-d=
ata">modified</td><td class=3D"modifications-data">jhoeller</td><td class=
=3D"modifications-data">src/org/springframework/beans/factory/support/Abstr=
actAutowireCapableBeanFactory.java</td><td class=3D"modifications-data">dep=
recated "getNrOfArguments" in favor of "getArgumentCount"</td></tr><tr clas=
s=3D"modifications-oddrow"><td class=3D"modifications-data">modified</td><t=
d class=3D"modifications-data">jhoeller</td><td class=3D"modifications-data=
">src/org/springframework/beans/factory/config/ConstructorArgumentValues.ja=
va</td><td class=3D"modifications-data">deprecated "getNrOfArguments" in fa=
vor of "getArgumentCount"</td></tr><tr class=3D"modifications-evenrow"><td =
class=3D"modifications-data">modified</td><td class=3D"modifications-data">=
jhoeller</td><td class=3D"modifications-data">src/org/springframework/aop/t=
arget/ThreadLocalTargetSource.java</td><td class=3D"modifications-data">ren=
amed "getNrOfXxx" methods to "getXxxCount"</td></tr><tr class=3D"modificati=
ons-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"modi=
fications-data">jhoeller</td><td class=3D"modifications-data">src/org/sprin=
gframework/aop/target/ThreadLocalTargetSourceStats.java</td><td class=3D"mo=
difications-data">renamed "getNrOfXxx" methods to "getXxxCount"</td></tr><t=
r class=3D"modifications-evenrow"><td class=3D"modifications-data">modified=
</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modificatio=
ns-data">test/org/springframework/aop/target/ThreadLocalTargetSourceTests.j=
ava</td><td class=3D"modifications-data">renamed "getNrOfXxx" methods to "g=
etXxxCount"</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifi=
cations-data">modified</td><td class=3D"modifications-data">jhoeller</td><t=
d class=3D"modifications-data">test/org/springframework/aop/support/Abstrac=
tRegexpMethodPointcutTests.java</td><td class=3D"modifications-data">rename=
d Jdk14RegexpMethodPointcut to JdkRegexpMethodPointcut</td></tr><tr class=
=3D"modifications-evenrow"><td class=3D"modifications-data">deleted</td><td=
 class=3D"modifications-data">jhoeller</td><td class=3D"modifications-data"=
>test/org/springframework/aop/support/Jdk14RegexpMethodPointcutTests.java</=
td><td class=3D"modifications-data">renamed Jdk14RegexpMethodPointcut to Jd=
kRegexpMethodPointcut</td></tr><tr class=3D"modifications-oddrow"><td class=
=3D"modifications-data">added</td><td class=3D"modifications-data">jhoeller=
</td><td class=3D"modifications-data">test/org/springframework/aop/support/=
JdkRegexpMethodPointcutTests.java</td><td class=3D"modifications-data">rena=
med Jdk14RegexpMethodPointcut to JdkRegexpMethodPointcut</td></tr><tr class=
=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td><t=
d class=3D"modifications-data">jhoeller</td><td class=3D"modifications-data=
">test/org/springframework/aop/support/Perl5RegexpMethodPointcutTests.java<=
/td><td class=3D"modifications-data">renamed Jdk14RegexpMethodPointcut to J=
dkRegexpMethodPointcut</td></tr><tr class=3D"modifications-oddrow"><td clas=
s=3D"modifications-data">modified</td><td class=3D"modifications-data">jhoe=
ller</td><td class=3D"modifications-data">src/org/springframework/aop/suppo=
rt/Perl5RegexpMethodPointcut.java</td><td class=3D"modifications-data">rena=
med Jdk14RegexpMethodPointcut to JdkRegexpMethodPointcut</td></tr><tr class=
=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td><t=
d class=3D"modifications-data">jhoeller</td><td class=3D"modifications-data=
">src/org/springframework/aop/support/RegexpMethodPointcut.java</td><td cla=
ss=3D"modifications-data">renamed Jdk14RegexpMethodPointcut to JdkRegexpMet=
hodPointcut</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifi=
cations-data">modified</td><td class=3D"modifications-data">jhoeller</td><t=
d class=3D"modifications-data">src/org/springframework/aop/support/Abstract=
RegexpMethodPointcut.java</td><td class=3D"modifications-data">renamed Jdk1=
4RegexpMethodPointcut to JdkRegexpMethodPointcut</td></tr><tr class=3D"modi=
fications-evenrow"><td class=3D"modifications-data">deleted</td><td class=
=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">src/o=
rg/springframework/aop/support/Jdk14RegexpMethodPointcut.java</td><td class=
=3D"modifications-data">renamed Jdk14RegexpMethodPointcut to JdkRegexpMetho=
dPointcut</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifica=
tions-data">added</td><td class=3D"modifications-data">jhoeller</td><td cla=
ss=3D"modifications-data">src/org/springframework/aop/support/JdkRegexpMeth=
odPointcut.java</td><td class=3D"modifications-data">renamed Jdk14RegexpMet=
hodPointcut to JdkRegexpMethodPointcut</td></tr><tr class=3D"modifications-=
evenrow"><td class=3D"modifications-data">modified</td><td class=3D"modific=
ations-data">jhoeller</td><td class=3D"modifications-data">samples/petclini=
c/war/WEB-INF/applicationContext-hibernate.xml</td><td class=3D"modificatio=
ns-data">made baseTransactionProxy abstract</td></tr><tr class=3D"modificat=
ions-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"mod=
ifications-data">jhoeller</td><td class=3D"modifications-data">samples/petc=
linic/war/WEB-INF/applicationContext-jdbc.xml</td><td class=3D"modification=
s-data">made baseTransactionProxy abstract</td></tr><tr class=3D"modificati=
ons-evenrow"><td class=3D"modifications-data">modified</td><td class=3D"mod=
ifications-data">jhoeller</td><td class=3D"modifications-data">samples/petc=
linic/war/WEB-INF/applicationContext-ojb.xml</td><td class=3D"modifications=
-data">made baseTransactionProxy abstract</td></tr><tr class=3D"modificatio=
ns-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"modif=
ications-data">jhoeller</td><td class=3D"modifications-data">samples/jpetst=
ore/war/WEB-INF/applicationContext.xml</td><td class=3D"modifications-data"=
>made baseTransactionProxy abstract</td></tr><tr class=3D"modifications-eve=
nrow"><td class=3D"modifications-data">modified</td><td class=3D"modificati=
ons-data">jhoeller</td><td class=3D"modifications-data">src/org/springframe=
work/orm/hibernate/HibernateObjectRetrievalFailureException.java</td><td cl=
ass=3D"modifications-data">pass along persistence class for ObjectDeletedEx=
ception too</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifi=
cations-data">modified</td><td class=3D"modifications-data">jhoeller</td><t=
d class=3D"modifications-data">src/org/springframework/orm/ObjectOptimistic=
LockingFailureException.java</td><td class=3D"modifications-data">added ove=
rloaded constructors that take a "persistentClassName"</td></tr><tr class=
=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td><t=
d class=3D"modifications-data">jhoeller</td><td class=3D"modifications-data=
">src/org/springframework/orm/ObjectRetrievalFailureException.java</td><td =
class=3D"modifications-data">added overloaded constructors that take a "per=
sistentClassName"</td></tr><tr class=3D"modifications-oddrow"><td class=3D"=
modifications-data">modified</td><td class=3D"modifications-data">jhoeller<=
/td><td class=3D"modifications-data">src/org/springframework/beans/factory/=
BeanIsNotAFactoryException.java</td><td class=3D"modifications-data">polish=
ing</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications=
-data">modified</td><td class=3D"modifications-data">jhoeller</td><td class=
=3D"modifications-data">src/org/springframework/beans/factory/BeanNotOfRequ=
iredTypeException.java</td><td class=3D"modifications-data">polishing</td><=
/tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">mod=
ified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modifi=
cations-data">test/org/springframework/transaction/interceptor/transactiona=
lBeanFactory.xml</td><td class=3D"modifications-data">added "abstract" attr=
ibute for XML bean definitions</td></tr><tr class=3D"modifications-evenrow"=
><td class=3D"modifications-data">modified</td><td class=3D"modifications-d=
ata">jhoeller</td><td class=3D"modifications-data">test/org/springframework=
/beans/factory/xml/XmlBeanFactoryTestSuite.java</td><td class=3D"modificati=
ons-data">added "abstract" attribute for XML bean definitions</td></tr><tr =
class=3D"modifications-oddrow"><td class=3D"modifications-data">modified</t=
d><td class=3D"modifications-data">jhoeller</td><td class=3D"modifications-=
data">test/org/springframework/beans/factory/xml/parent.xml</td><td class=
=3D"modifications-data">added "abstract" attribute for XML bean definitions=
</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-da=
ta">modified</td><td class=3D"modifications-data">jhoeller</td><td class=3D=
"modifications-data">test/org/springframework/transaction/interceptor/BeanF=
actoryTransactionTests.java</td><td class=3D"modifications-data">added "abs=
tract" attribute for XML bean definitions</td></tr><tr class=3D"modificatio=
ns-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"modif=
ications-data">jhoeller</td><td class=3D"modifications-data">src/org/spring=
framework/beans/factory/xml/DefaultXmlBeanDefinitionParser.java</td><td cla=
ss=3D"modifications-data">added "abstract" attribute for XML bean definitio=
ns</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-=
data">modified</td><td class=3D"modifications-data">jhoeller</td><td class=
=3D"modifications-data">src/org/springframework/beans/factory/xml/spring-be=
ans.dtd</td><td class=3D"modifications-data">added "abstract" attribute for=
 XML bean definitions</td></tr><tr class=3D"modifications-oddrow"><td class=
=3D"modifications-data">added</td><td class=3D"modifications-data">jhoeller=
</td><td class=3D"modifications-data">src/org/springframework/beans/factory=
/BeanIsAbstractException.java</td><td class=3D"modifications-data">added su=
pport for "abstract" bean definitions</td></tr><tr class=3D"modifications-e=
venrow"><td class=3D"modifications-data">modified</td><td class=3D"modifica=
tions-data">jhoeller</td><td class=3D"modifications-data">src/org/springfra=
mework/beans/factory/support/AbstractBeanDefinition.java</td><td class=3D"m=
odifications-data">added support for "abstract" bean definitions</td></tr><=
tr class=3D"modifications-oddrow"><td class=3D"modifications-data">modified=
</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modificatio=
ns-data">src/org/springframework/beans/factory/support/AbstractBeanFactory.=
java</td><td class=3D"modifications-data">added support for "abstract" bean=
 definitions</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modi=
fications-data">modified</td><td class=3D"modifications-data">jhoeller</td>=
<td class=3D"modifications-data">src/org/springframework/beans/factory/supp=
ort/DefaultListableBeanFactory.java</td><td class=3D"modifications-data">ad=
ded support for "abstract" bean definitions</td></tr><tr class=3D"modificat=
ions-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"mod=
ifications-data">jhoeller</td><td class=3D"modifications-data">src/org/spri=
ngframework/beans/factory/config/BeanDefinition.java</td><td class=3D"modif=
ications-data">added "isAbstract", "isSingleton", "isLazyInit"</td></tr><tr=
 class=3D"modifications-evenrow"><td class=3D"modifications-data">modified<=
/td><td class=3D"modifications-data">jhoeller</td><td class=3D"modification=
s-data">src/org/springframework/beans/factory/config/ConfigurableBeanFactor=
y.java</td><td class=3D"modifications-data">moved "getBeanDefinition" metho=
d from ConfigurableBeanFactory down to ConfigurableListableBeanFactory inte=
rface</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modification=
s-data">modified</td><td class=3D"modifications-data">jhoeller</td><td clas=
s=3D"modifications-data">src/org/springframework/beans/factory/config/Confi=
gurableListableBeanFactory.java</td><td class=3D"modifications-data">moved =
"getBeanDefinition" method from ConfigurableBeanFactory down to Configurabl=
eListableBeanFactory interface</td></tr><tr class=3D"modifications-evenrow"=
><td class=3D"modifications-data">modified</td><td class=3D"modifications-d=
ata">jhoeller</td><td class=3D"modifications-data">src/org/springframework/=
aop/target/AbstractPrototypeBasedTargetSource.java</td><td class=3D"modific=
ations-data">moved "getBeanDefinition" method from ConfigurableBeanFactory =
down to ConfigurableListableBeanFactory interface</td></tr><tr class=3D"mod=
ifications-oddrow"><td class=3D"modifications-data">modified</td><td class=
=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">src/o=
rg/springframework/beans/BeanUtils.java</td><td class=3D"modifications-data=
">polished exception messages</td></tr><tr class=3D"modifications-evenrow">=
<td class=3D"modifications-data">modified</td><td class=3D"modifications-da=
ta">jhoeller</td><td class=3D"modifications-data">mock/org/springframework/=
mock/jndi/SimpleNamingContextBuilder.java</td><td class=3D"modifications-da=
ta">polishing</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modi=
fications-data">modified</td><td class=3D"modifications-data">jhoeller</td>=
<td class=3D"modifications-data">src/org/springframework/web/servlet/view/A=
bstractTemplateView.java</td><td class=3D"modifications-data">polishing</td=
></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-data">=
modified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"mod=
ifications-data">src/org/springframework/jdbc/datasource/TransactionAwareDa=
taSourceProxy.java</td><td class=3D"modifications-data">polishing</td></tr>=
<tr class=3D"modifications-oddrow"><td class=3D"modifications-data">modifie=
d</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modificati=
ons-data">src/org/springframework/orm/hibernate/HibernateInterceptor.java</=
td><td class=3D"modifications-data">polishing</td></tr><tr class=3D"modific=
ations-evenrow"><td class=3D"modifications-data">modified</td><td class=3D"=
modifications-data">jhoeller</td><td class=3D"modifications-data">src/org/s=
pringframework/orm/hibernate/HibernateTemplate.java</td><td class=3D"modifi=
cations-data">polishing</td></tr><tr class=3D"modifications-oddrow"><td cla=
ss=3D"modifications-data">modified</td><td class=3D"modifications-data">jho=
eller</td><td class=3D"modifications-data">test/org/springframework/beans/B=
eanUtilsTests.java</td><td class=3D"modifications-data">check copyPropertie=
s with null value</td></tr><tr class=3D"modifications-evenrow"><td class=3D=
"modifications-data">modified</td><td class=3D"modifications-data">jhoeller=
</td><td class=3D"modifications-data">test/org/springframework/jdbc/core/su=
pport/JdbcBeanDefinitionReaderTests.java</td><td class=3D"modifications-dat=
a">polishing</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modif=
ications-data">modified</td><td class=3D"modifications-data">dkopylenko</td=
><td class=3D"modifications-data">/changelog.txt</td><td class=3D"modificat=
ions-data">added Jdk14RegexpMethodPointcut entry</td></tr><tr class=3D"modi=
fications-evenrow"><td class=3D"modifications-data">modified</td><td class=
=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">/chan=
gelog.txt</td><td class=3D"modifications-data">refined JavaMail support</td=
></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">m=
odified</td><td class=3D"modifications-data">markpollack</td><td class=3D"m=
odifications-data">test/org/springframework/aop/framework/ProxyFactoryBeanT=
ests.java</td><td class=3D"modifications-data">comment back in testNoInterc=
eptorNamesWithTarget.  It was accidentally omitted.</td></tr><tr class=3D"m=
odifications-evenrow"><td class=3D"modifications-data">modified</td><td cla=
ss=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">src=
/org/springframework/scheduling/quartz/JobDetailBean.java</td><td class=3D"=
modifications-data">polishing</td></tr><tr class=3D"modifications-oddrow"><=
td class=3D"modifications-data">modified</td><td class=3D"modifications-dat=
a">jhoeller</td><td class=3D"modifications-data">src/org/springframework/ui=
/velocity/VelocityEngineUtils.java</td><td class=3D"modifications-data">pol=
ishing</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modificati=
ons-data">modified</td><td class=3D"modifications-data">jhoeller</td><td cl=
ass=3D"modifications-data">src/org/springframework/mail/MailSender.java</td=
><td class=3D"modifications-data">polishing</td></tr><tr class=3D"modificat=
ions-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"mod=
ifications-data">jhoeller</td><td class=3D"modifications-data">samples/imag=
edb/src/org/springframework/samples/imagedb/DefaultImageDatabase.java</td><=
td class=3D"modifications-data">polishing</td></tr><tr class=3D"modificatio=
ns-evenrow"><td class=3D"modifications-data">modified</td><td class=3D"modi=
fications-data">jhoeller</td><td class=3D"modifications-data">src/org/sprin=
gframework/mail/javamail/MimeMessagePreparator.java</td><td class=3D"modifi=
cations-data">allow MimeMessagePreparator implementations to throw any Exce=
ption</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modification=
s-data">modified</td><td class=3D"modifications-data">jhoeller</td><td clas=
s=3D"modifications-data">src/org/springframework/mail/javamail/JavaMailSend=
er.java</td><td class=3D"modifications-data">added "createMimeMessage(Input=
Stream)" method</td></tr><tr class=3D"modifications-evenrow"><td class=3D"m=
odifications-data">modified</td><td class=3D"modifications-data">jhoeller</=
td><td class=3D"modifications-data">src/org/springframework/mail/javamail/J=
avaMailSenderImpl.java</td><td class=3D"modifications-data">added "createMi=
meMessage(InputStream)" method</td></tr><tr class=3D"modifications-oddrow">=
<td class=3D"modifications-data">modified</td><td class=3D"modifications-da=
ta">jhoeller</td><td class=3D"modifications-data">src/org/springframework/b=
eans/factory/support/AbstractAutowireCapableBeanFactory.java</td><td class=
=3D"modifications-data">added "applyBeanPropertyValues" method, for applyin=
g property values from a bean definition to an existing bean instance</td><=
/tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-data">mo=
dified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modif=
ications-data">test/org/springframework/beans/factory/DefaultListableBeanFa=
ctoryTestSuite.java</td><td class=3D"modifications-data">added "applyBeanPr=
opertyValues" method, for applying property values from a bean definition t=
o an existing bean instance</td></tr><tr class=3D"modifications-oddrow"><td=
 class=3D"modifications-data">modified</td><td class=3D"modifications-data"=
>jhoeller</td><td class=3D"modifications-data">src/org/springframework/bean=
s/factory/config/AutowireCapableBeanFactory.java</td><td class=3D"modificat=
ions-data">added "applyBeanPropertyValues" method, for applying property va=
lues from a bean definition to an existing bean instance</td></tr><tr class=
=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td><t=
d class=3D"modifications-data">jhoeller</td><td class=3D"modifications-data=
">sandbox/src/org/springframework/validation/commons/taglib/JavascriptValid=
atorTag.java</td><td class=3D"modifications-data">check servlet-specific We=
bApplicationContext first when looking for ValidatorFactory</td></tr></tabl=
e><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"distributables-sectionheader">                =
        &nbsp;Deployments by this build:&nbsp;(8)                    </td><=
/tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/checko=
ut/spring/spring/dist/spring.jar</td></tr><tr class=3D"distributables-oddro=
w"><td class=3D"distributables-data">Building war: /jteam/build/checkout/sp=
ring/spring/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr><td c=
lass=3D"distributables-data">Building war: /jteam/build/checkout/spring/spr=
ing/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr class=3D"dist=
ributables-oddrow"><td class=3D"distributables-data">Building war: /jteam/b=
uild/checkout/spring/spring/autobuilds/apps/buildtest/dist/buildtest.war</t=
d></tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/che=
ckout/spring/spring/autobuilds/apps/jpetstore/war/WEB-INF/lib/jpetstore.jar=
</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distributables-d=
ata">Building war: /jteam/build/checkout/spring/spring/autobuilds/apps/jpet=
store/dist/jpetstore.war</td></tr><tr><td class=3D"distributables-data">Bui=
lding jar: /jteam/build/checkout/spring/spring/autobuilds/apps/jpetstore/wa=
r/WEB-INF/lib/jpetstore.jar</td></tr><tr class=3D"distributables-oddrow"><t=
d class=3D"distributables-data">Building war: /jteam/build/checkout/spring/=
spring/autobuilds/apps/jpetstore/dist/jpetstore.war</td></tr></table>
</body></html>

Re: [Springframework-developer] StatementCreatorUtils

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

Good point. However, the driver respectively database might behave =
differently, as the passed-in object implicitly leads to a corresponding =
SQL type (i.e. DATE or TIMESTAMP): Will the database complain if it =
receives a timestamp value for a date field? Will it complain the other =
way round?
=20
It's certainly recommendable to pass the SQL type in for such a value. =
The question is: What's the safest default for the type if we receive a =
plain java.util.Date? Which implicit SQL type will work with most =
databases in a predictable manner?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von tho...@tr...
Gesendet: Di 31.08.2004 22:56
An: spr...@li...
Betreff: Re: [Springframework-developer] StatementCreatorUtils



Wouldn't java.sql.Timestamp be a better choice for java.util.Date and
java.util.Calendar with unknow SQL type?  That way you would not lose =
the time
portion.

Thomas


Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>:

> I've adapted StatementCreatorUtils as follows:
>
> * StatementCreatorUtils uses specific PreparedStatement parameter =
setter =3D
> methods, as far as possible
> * added auto-conversion of java.util.Calendar to =3D
> java.sql.Date/Time/Timestamp, for SQL types DATE/TIME/TIMESTAMP
> * added auto-conversion of java.util.Date and java.util.Calendar to =
=3D
> java.sql.Date, in case of an unknown SQL type
>
> This was partly triggered by
> http://opensource.atlassian.com/projects/spring/browse/SPR-301
>
> Thomas and co, please give the new version a try. It should =
essentially =3D
> work the same as before, just do a few more auto-conversions.
>
> Juergen
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>





-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] trying to extend AbstractXmlApplicationContext

[bryan <nih...@gm...>]

First off appologies for cross-posting :-(=20

/*
 * Created on 30 ao=FBt 2004 bryan hunt licence LGPL
 */
package ie.jestate.temp.spring;

import ie.jestate.spring.service.ISystemUserService;
import ie.jestate.util.ApplicationContextFactory;

import java.util.HashMap;
import java.util.HashSet;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;

import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import org.springframework.context.support.AbstractXmlApplicationContext;

/**
 * @author Administrateur
 *
 */
public class ConditionalClassPathXMLApplicationContext=20
extends AbstractXmlApplicationContext implements ApplicationContextAware{
 =20

    public static void main(String[] args) {
       =20
        Map mappings =3D new HashMap();
        mappings.put("jestate.unit.testing=3Denabled","/test/ie/jestate/spr=
ing/unit-testing.xml");
       =20
        Map variables =3D new HashMap();
        variables.put("jestate.unit.testing","enabled");
       =20
               =20
        ConditionalClassPathXMLApplicationContext test =3D new
ConditionalClassPathXMLApplicationContext(mappings,variables);
        ISystemUserService systemUserService =3D (ISystemUserService)
test.getBean("SystemUserService");
        System.out.println(systemUserService.toString());
   =20
    }

    private String[] configLocations ;
    /**
     * Matches mappings to variables and then loads appropriate
application contexts
     * @param mappings of the form
("jestate.testing=3Dtrue","classpath:test/ie/jestate/spring/application.xml=
")
     * @param variables or the form("jestate.testing","true");
     * @throws BeansException
     */

    public ConditionalClassPathXMLApplicationContext(Map mappings, Map
variables)
            throws BeansException {
        super();
        Set mappingKeys =3D mappings.keySet();
        Set variableKeys =3D variables.keySet();
        Set configLocationSet =3D new HashSet();
        Iterator variableKeysIterator =3D variableKeys.iterator();
       =20
        while (variableKeysIterator.hasNext()) {
           =20
           =20
            String  variableKey  =3D (String ) variableKeysIterator.next();
            String mapping =3D (String) variables.get(variableKey);
            String mappingKey =3D variableKey + "=3D" + mapping;
            logger.debug("mappingKey=3D'" + mappingKey + "'");
            logger.debug("mappings.get(mappingKey)=3D'" +
mappings.get(mappingKey) + "'");
            if(mappings.get(mappingKey) !=3D null) {
                configLocationSet.add(mappings.get(mappingKey));
            }
        }
       =20
        configLocations =3D new String[configLocationSet.size()];
      =20
        Iterator iterator =3D configLocationSet.iterator();
       =20
       =20
        configLocations =3D (String[]) configLocationSet.toArray(configLoca=
tions);
       =20
        for (int i =3D 0; i < 3; i++) {
            logger.info("******* Config start *********");
        }
       =20
       =20
        for (int ii =3D 0; ii < configLocations.length; ii++) {
            logger.info(configLocations[ii]);
            }       =20
       =20
        for (int i =3D 0; i < 10; i++) {
            logger.info("******* Config end *********");
        }
        refresh();
    }

    /* (non-Javadoc)
     * @see org.springframework.context.support.AbstractXmlApplicationConte=
xt#getConfigLocations()
     */
    protected String[] getConfigLocations() {
        return configLocations;
    }

    /* (non-Javadoc)
     * @see org.springframework.context.ApplicationContextAware#setApplicat=
ionContext(org.springframework.context.ApplicationContext)
     */
    public void setApplicationContext(ApplicationContext
applicationContext) throws BeansException {
       =20
        this.setParent(applicationContext);
       =20
        refresh();
       =20
    }
   =20
}


When I test this class using it's main method it works just fine but
when I test it
in this fashion ...
return new ClassPathXmlApplicationContext("classpath:/ie/jestate/spring/app=
lication.xml");

it displays strange behaviour.

The log files show that it is loading the beans as so ...

[@APPNAME@] INFO [main]
HibernateTransactionManager.afterPropertiesSet(231) | Using DataSource
[org.apache.commons.dbcp.BasicDataSource@14275d4] from Hibernate
SessionFactory for HibernateTransactionManager
[@APPNAME@] INFO [main] AbstractBeanFactory.getBean(158) | Creating
shared instance of singleton bean 'myHibernateInterceptor'

NOTE THIS LINE !!!!!!!!!!!!!!!!

[@APPNAME@] INFO [main] AbstractBeanFactory.getBean(158) | Creating
shared instance of singleton bean 'PropertyService'


[@APPNAME@] INFO [main] AbstractBeanFactory.getBean(158) | Creating
shared instance of singleton bean 'PropertyDAO'

But when I try to access them ie "PropertyService" ie get the following
exception ....

) testAddProperty(test.ie.jestate.spring.service.PropertyServiceTest)org.sp=
ringframework.beans.factory.NoSuchBeanDefinitionException:
No bean named 'PropertyService' is defined:
org.springframework.beans.factory.support.DefaultListableBeanFactory
defining beans [contextConfigurer]; Root of BeanFactory hierarchy
at org.springframework.beans.factory.support.DefaultListableBeanFactory.get=
BeanDefinition(DefaultListableBeanFactory.java:226)
at org.springframework.beans.factory.support.AbstractBeanFactory.getMergedB=
eanDefinition(AbstractBeanFactory.java:488)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab=
stractBeanFactory.java:143)
at org.springframework.context.support.AbstractApplicationContext.getBean(A=
bstractApplicationContext.java:394)
at test.ie.jestate.spring.service.PropertyServiceTest.setUp(PropertyService=
Test.java:62)
at test.ie.jestate.spring.service.PropertyServiceTest.main(PropertyServiceT=
est.java:66)


I am guessing that I have to do something to make it aware of it's
parent but I am't
quite sure what. I'm quite new to spring and haven't found anything obvious=
 in=20
the documentation.

Any help would be much appreciated and I hope that my code can be used in=
=20
the spring framework.

--b

Re: [Springframework-developer] StatementCreatorUtils

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

Wouldn't java.sql.Timestamp be a better choice for java.util.Date and
java.util.Calendar with unknow SQL type?  That way you would not lose the time
portion.

Thomas


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

> I've adapted StatementCreatorUtils as follows:
>
> * StatementCreatorUtils uses specific PreparedStatement parameter setter =
> methods, as far as possible
> * added auto-conversion of java.util.Calendar to =
> java.sql.Date/Time/Timestamp, for SQL types DATE/TIME/TIMESTAMP
> * added auto-conversion of java.util.Date and java.util.Calendar to =
> java.sql.Date, in case of an unknown SQL type
>
> This was partly triggered by
> http://opensource.atlassian.com/projects/spring/browse/SPR-301
>
> Thomas and co, please give the new version a try. It should essentially =
> work the same as before, just do a few more auto-conversions.
>
> Juergen
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] StatementCreatorUtils

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

Except that now java.sql.Timestamp/Time are autoconverted to java.sql.Date since
they are both subclasses of java.util.Date.  I made the fix to bypass
autoconversion for them too.  Otherwise it seems to work well.

Thomas


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

> I've adapted StatementCreatorUtils as follows:
>
> * StatementCreatorUtils uses specific PreparedStatement parameter setter =
> methods, as far as possible
> * added auto-conversion of java.util.Calendar to =
> java.sql.Date/Time/Timestamp, for SQL types DATE/TIME/TIMESTAMP
> * added auto-conversion of java.util.Date and java.util.Calendar to =
> java.sql.Date, in case of an unknown SQL type
>
> This was partly triggered by
> http://opensource.atlassian.com/projects/spring/browse/SPR-301
>
> Thomas and co, please give the new version a try. It should essentially =
> work the same as before, just do a few more auto-conversions.
>
> Juergen
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] OJB PB Support: Why only partial?

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

Outside of a transaction, each PersistenceBrokerTemplate operation will =
use its own PersistenceBroker instance. Within a transaction, it will =
participate in the transactional, thread-bound PersistenceBroker. So =
with typical setup, you'll get the same PersistenceBroker throughout a =
transaction. With multiple transactions, you'll get multiple =
PersistenceBrokers - one per transaction.
=20
There is no automatical thread-binding for the scope of a web request. =
In the Hibernate case, OpenSessionInViewFilter will give you just that: =
Transactions will then automatically participate in that existing =
thread-bound Session. The main benefit of OpenSessionInViewFilter is =
that lazy loading is possible during view rendering: In Hibernate, the =
original Session needs to be open to allow for lazy loading.
=20
In the OJB case, one PersistenceBroker per web request doesn't seem to =
give such significant benefits: Lazy loading is possible there even with =
the original PersistenceBroker already closed. The only benefit would be =
a shared PB-level cache per web request. But on the other hand, you =
should use very few transactions (ideally just one) per web request =
anyway, sharing a PB-level cache per transaction.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Clute, Andrew
Gesendet: Di 31.08.2004 17:01
An: spr...@li...
Betreff: RE: [Springframework-developer] OJB PB Support: Why only =
partial?


Juergen,
=20
Thanks for the quick feedback!
=20
After reading your message, I now have a much better understanding about =
the pattern for using the Callbacks. Based on that, you are correct, =
methods like getClassDescriptor are part of a larger, interrelated set, =
and should use a Callback -- I am using it to implement my own deep save =
and deep cache removal, which allows me to do it programmatically, =
versus declaratively with the repository.xml.=20
=20
The one statement you did make sort of put what I thought to understand =
about using the PBTemplate in question -- "
This is particularly recommendable for operations that involve multiple =
interrelated PersistenceBroker calls. Any such callback will =
automatically participate in Spring's resource and transaction =
management, just like the convenience operations do."
=20
My understanding is that by using the =
PersistenceBrokerTransactionManager, the life of my request (web =
request) that is tied to a thread, will be tied to a single =
PersistenceBroker instance. And more importantly, based upon my TX =
declarations, will happen inside the same TX as well. At the same time =
when the request is finished, it will also close the PB instance. Is =
this an accurate understanding?
=20
Thanks!
-Andrew
=20

________________________________

From: spr...@li... =
[mailto:spr...@li...] On Behalf =
Of j=FCrgen h=F6ller [werk3AT]
Sent: Tuesday, August 31, 2004 10:34 AM
To: spr...@li...
Subject: Re: [Springframework-developer] OJB PB Support: Why only =
partial?


Indeed, the convenience operations on PersistenceBrokerTemplate are just =
a subset. Note that you can always implement your own =
PersistenceBrokerCallback, working with the raw PersistenceBroker. For =
example:
=20
Object myObject =3D getPersistenceBrokerTemplate().execute(new =
PersistenceBrokerCallback() {
  public Object doInPersistenceBroker(PersistenceBroker pb) {
    return pb.getObjectByIdentity(new Identity(...));
  }
});
=20
This is particularly recommendable for operations that involve multiple =
interrelated PersistenceBroker calls. Any such callback will =
automatically participate in Spring's resource and transaction =
management, just like the convenience operations do.
=20
If there are further typical convenience operations that make sense on =
PersistenceBrokerTemplate itself, I'm open to adding them:
=20
* getReportQueryIteratorByQuery is an obvious candidate. I've just added =
it.
=20
* getObjectByIdentity does not seem to be intended for direct usage, =
according to the OJB javadocs. The main issue is: Where do you get the =
Identity parameter from? As this is unlikely to come in from the =
outside, it's probably appropriate to just use getObjectByIdentity as =
part of a sequence of calls within a PersistenceBrokerCallback.
=20
* getClassDescriptor seems like a method typically used as part of a =
larger sequence too, so also rather to be used within a =
PersistenceBrokerCallback.
=20
If I'm wrong in terms of the typical use cases for the latter two, feel =
free to try to convince me :-)
=20
Juergen
=20
=20

	-----Original Message-----
	From: spr...@li... =
[mailto:spr...@li...]On Behalf =
Of Clute, Andrew
	Sent: Tuesday, August 31, 2004 4:06 PM
	To: spr...@li...
	Subject: [Springframework-developer] OJB PB Support: Why only partial?
=09
=09

	Since the release of 1.1RC2, I have been attempting to retrofit Spring =
into my system and remove my EJB's. We make heavy use of OJB's =
PersistenceBroker API, and as such, I was hoping to utilize the =
PersistenceBrokerDaoSupport, with the PersistenceBrokerTemplate.=20

	However, it seems that PersistenceBrokerTemplate only supports a subset =
of the methods that PB has on it, with the three major missing ones =
being findObjectByIdentity, getReportQueryIteratorByQuery and =
getClassDescriptor.

	Was there a conscious decision to leave these methods out, or was it =
just an oversight/timing issue? I would be happy to implement these =
methods and submit the changes back to the group, but I wanted to =
confirm that there wasn't a specific reason for leaving these off.

	Thanks!=20

	-Andrew=20

Re: [Springframework-developer] Setting JDBC null values

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

I posted a comment on this issue
http://opensource.atlassian.com/projects/spring/browse/SPR-297#action_10904

Bottom line is that the latest Oracle 10g driver works fine and I would prefer
to leave the code as is at least until we have time to test and verify that any
alternate soutions will not cause issues with other jdbc drivers.

Thomas


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

> http://opensource.atlassian.com/projects/spring/browse/SPR-297
>
> Any experience with this, possibly on multiple databases?
>
> Juergen
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] StatementCreatorUtils

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

I've adapted StatementCreatorUtils as follows:

* StatementCreatorUtils uses specific PreparedStatement parameter setter =
methods, as far as possible
* added auto-conversion of java.util.Calendar to =
java.sql.Date/Time/Timestamp, for SQL types DATE/TIME/TIMESTAMP
* added auto-conversion of java.util.Date and java.util.Calendar to =
java.sql.Date, in case of an unknown SQL type

This was partly triggered by
http://opensource.atlassian.com/projects/spring/browse/SPR-301

Thomas and co, please give the new version a try. It should essentially =
work the same as before, just do a few more auto-conversions.

Juergen

RE: [Springframework-developer] OJB PB Support: Why only partial?

[Clute, A. <And...@os...>]

Juergen,
=20
Thanks for the quick feedback!
=20
After reading your message, I now have a much better understanding about =
the pattern for using the Callbacks. Based on that, you are correct, =
methods like getClassDescriptor are part of a larger, interrelated set, =
and should use a Callback -- I am using it to implement my own deep save =
and deep cache removal, which allows me to do it programmatically, =
versus declaratively with the repository.xml.=20
=20
The one statement you did make sort of put what I thought to understand =
about using the PBTemplate in question -- "
This is particularly recommendable for operations that involve multiple =
interrelated PersistenceBroker calls. Any such callback will =
automatically participate in Spring's resource and transaction =
management, just like the convenience operations do."
=20
My understanding is that by using the =
PersistenceBrokerTransactionManager, the life of my request (web =
request) that is tied to a thread, will be tied to a single =
PersistenceBroker instance. And more importantly, based upon my TX =
declarations, will happen inside the same TX as well. At the same time =
when the request is finished, it will also close the PB instance. Is =
this an accurate understanding?
=20
Thanks!
-Andrew
=20

________________________________

From: spr...@li... =
[mailto:spr...@li...] On Behalf =
Of j=FCrgen h=F6ller [werk3AT]
Sent: Tuesday, August 31, 2004 10:34 AM
To: spr...@li...
Subject: Re: [Springframework-developer] OJB PB Support: Why only =
partial?


Indeed, the convenience operations on PersistenceBrokerTemplate are just =
a subset. Note that you can always implement your own =
PersistenceBrokerCallback, working with the raw PersistenceBroker. For =
example:
=20
Object myObject =3D getPersistenceBrokerTemplate().execute(new =
PersistenceBrokerCallback() {
  public Object doInPersistenceBroker(PersistenceBroker pb) {
    return pb.getObjectByIdentity(new Identity(...));
  }
});
=20
This is particularly recommendable for operations that involve multiple =
interrelated PersistenceBroker calls. Any such callback will =
automatically participate in Spring's resource and transaction =
management, just like the convenience operations do.
=20
If there are further typical convenience operations that make sense on =
PersistenceBrokerTemplate itself, I'm open to adding them:
=20
* getReportQueryIteratorByQuery is an obvious candidate. I've just added =
it.
=20
* getObjectByIdentity does not seem to be intended for direct usage, =
according to the OJB javadocs. The main issue is: Where do you get the =
Identity parameter from? As this is unlikely to come in from the =
outside, it's probably appropriate to just use getObjectByIdentity as =
part of a sequence of calls within a PersistenceBrokerCallback.
=20
* getClassDescriptor seems like a method typically used as part of a =
larger sequence too, so also rather to be used within a =
PersistenceBrokerCallback.
=20
If I'm wrong in terms of the typical use cases for the latter two, feel =
free to try to convince me :-)
=20
Juergen
=20
=20

	-----Original Message-----
	From: spr...@li... =
[mailto:spr...@li...]On Behalf =
Of Clute, Andrew
	Sent: Tuesday, August 31, 2004 4:06 PM
	To: spr...@li...
	Subject: [Springframework-developer] OJB PB Support: Why only partial?
=09
=09

	Since the release of 1.1RC2, I have been attempting to retrofit Spring =
into my system and remove my EJB's. We make heavy use of OJB's =
PersistenceBroker API, and as such, I was hoping to utilize the =
PersistenceBrokerDaoSupport, with the PersistenceBrokerTemplate.=20

	However, it seems that PersistenceBrokerTemplate only supports a subset =
of the methods that PB has on it, with the three major missing ones =
being findObjectByIdentity, getReportQueryIteratorByQuery and =
getClassDescriptor.

	Was there a conscious decision to leave these methods out, or was it =
just an oversight/timing issue? I would be happy to implement these =
methods and submit the changes back to the group, but I wanted to =
confirm that there wasn't a specific reason for leaving these off.

	Thanks!=20

	-Andrew=20

Re: [Springframework-developer] OJB PB Support: Why only partial?

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

Indeed, the convenience operations on PersistenceBrokerTemplate are just =
a subset. Note that you can always implement your own =
PersistenceBrokerCallback, working with the raw PersistenceBroker. For =
example:
=20
Object myObject =3D getPersistenceBrokerTemplate().execute(new =
PersistenceBrokerCallback() {
  public Object doInPersistenceBroker(PersistenceBroker pb) {
    return pb.getObjectByIdentity(new Identity(...));
  }
});
=20
This is particularly recommendable for operations that involve multiple =
interrelated PersistenceBroker calls. Any such callback will =
automatically participate in Spring's resource and transaction =
management, just like the convenience operations do.
=20
If there are further typical convenience operations that make sense on =
PersistenceBrokerTemplate itself, I'm open to adding them:
=20
* getReportQueryIteratorByQuery is an obvious candidate. I've just added =
it.
=20
* getObjectByIdentity does not seem to be intended for direct usage, =
according to the OJB javadocs. The main issue is: Where do you get the =
Identity parameter from? As this is unlikely to come in from the =
outside, it's probably appropriate to just use getObjectByIdentity as =
part of a sequence of calls within a PersistenceBrokerCallback.
=20
* getClassDescriptor seems like a method typically used as part of a =
larger sequence too, so also rather to be used within a =
PersistenceBrokerCallback.
=20
If I'm wrong in terms of the typical use cases for the latter two, feel =
free to try to convince me :-)
=20
Juergen
=20
=20

-----Original Message-----
From: spr...@li... =
[mailto:spr...@li...]On Behalf =
Of Clute, Andrew
Sent: Tuesday, August 31, 2004 4:06 PM
To: spr...@li...
Subject: [Springframework-developer] OJB PB Support: Why only partial?



Since the release of 1.1RC2, I have been attempting to retrofit Spring =
into my system and remove my EJB's. We make heavy use of OJB's =
PersistenceBroker API, and as such, I was hoping to utilize the =
PersistenceBrokerDaoSupport, with the PersistenceBrokerTemplate.=20

However, it seems that PersistenceBrokerTemplate only supports a subset =
of the methods that PB has on it, with the three major missing ones =
being findObjectByIdentity, getReportQueryIteratorByQuery and =
getClassDescriptor.

Was there a conscious decision to leave these methods out, or was it =
just an oversight/timing issue? I would be happy to implement these =
methods and submit the changes back to the group, but I wanted to =
confirm that there wasn't a specific reason for leaving these off.

Thanks!=20

-Andrew=20

[Springframework-developer] OJB PB Support: Why only partial?

[Clute, A. <And...@os...>]

Since the release of 1.1RC2, I have been attempting to retrofit Spring
into my system and remove my EJB's. We make heavy use of OJB's
PersistenceBroker API, and as such, I was hoping to utilize the
PersistenceBrokerDaoSupport, with the PersistenceBrokerTemplate.=20

However, it seems that PersistenceBrokerTemplate only supports a subset
of the methods that PB has on it, with the three major missing ones
being findObjectByIdentity, getReportQueryIteratorByQuery and
getClassDescriptor.

Was there a conscious decision to leave these methods out, or was it
just an oversight/timing issue? I would be happy to implement these
methods and submit the changes back to the group, but I wanted to
confirm that there wasn't a specific reason for leaving these off.

Thanks!

-Andrew

[Springframework-developer] Setting JDBC null values

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

http://opensource.atlassian.com/projects/spring/browse/SPR-297

Any experience with this, possibly on multiple databases?

Juergen

Re: [Springframework-developer] JTA transaction suspension on WebSphere

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

Indeed, Thomas: I've pointed out exactly the same to Eugene on that =
WebLogic issue in JIRA.
=20
FYI, I've just noticed that I might have misinterpreted Victor's problem =
last night: He doesn't use Spring transactions with REQUIRES_NEW, but =
rather an outer Spring transaction plus an inner EJB CMT transaction =
with REQUIRES_NEW. Spring's JtaTransactionManager never touches the JTA =
TransactionManager is such a scenario, so it can't be caused by the =
suspend/resume interaction there.
=20
I rather suspect that the problem is Spring's transaction =
synchronization, which gets activated for the outer Spring transaction, =
but doesn't get notified of the transaction suspension caused by the =
inner EJB CMT transaction. Therefore, Spring's Hibernate support within =
the inner transaction will still synchronize with the outer Spring =
transaction, flushing the Hibernate Session at completion of the *outer* =
rather than the inner transaction.
=20
The solution I've suggested is to turn off Spring's transaction =
synchronization in that case. It should always be turned off when using =
transaction suspension driven by EJB CMT. See my JIRA comments:
=20
http://opensource.atlassian.com/projects/spring/browse/SPR-295
=20
As I've noted there, it would still be interesting whether Spring-driven =
JTA transaction suspension works with WebSphere: i.e., a Spring =
transaction demarcation with REQUIRES_NEW in case of an existing =
transaction. We might still face problems there, of course, but it seems =
to me that Victor's issue is not an indication for those.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Thomas Risberg
Gesendet: Di 31.08.2004 06:33
An: spr...@li...
Betreff: Re: [Springframework-developer] JTA transaction suspension on =
WebSphere



This is not an issue for transactions declared with REQUIRED, SUPPORTS,
MANDATORY or NEVER.  For these transactions there is no need to mess
with the JTA TransactionManager to suspend the current transaction.=20
UserTransaction is sufficient for these and this should be portable
between containers.

The only trouble is with REQUIRES_NEW and NOT_SUPPORTED.  Here we have
to bend the rules and use the JTA TransactionManager API if it is
available.  This is where things break down since the appservers don't
seem to cooperate.  Even WebLogic 8.1 did not work until we used a
WebLogic specific API call (forceResume).

Thomas


Colin Sampaleanu wrote:

> Eugene Kuleshov wrote:
>
>> Colin Sampaleanu wrote:
>>
>>> 'Eu' on his blog 3-4 days ago commented based on my own blog entry,
>>> and a forum message:
>>>  =
http://jroller.com/page/eu/20040826#using_spring_jta_interfaces_from
>>> that section / C.2.4 /of the EJB spec says that the container, for
>>> EJBs, must implement the UserTransaction interface (and JTA 1.0.1)
>>> extension, but doesn't have to implement the other interfaces
>>> defined in the JTA specification. Fine, I've actually seen that
>>> before, coincidentally, when I was tracking something down a while
>>> ago, but I think a container is fundamentally broken if it _does_
>>> expose the JTA TransactionManager interface, and it doesn't behave
>>> as per the spec. The spec for an API is the spec for the API. If you
>>> expose the interface at all, then you need to expose it correctly...
>>> That's essentially how I read that clause, and how I see things. In
>>> any case, I hope the situation is going to improve, certainly WLS 8
>>> works where WLS 7 doesn't, with out WL specific adapter...
>>
>>
>>
>>   Perhaps I wasn't clear enough. My point is that it is a bad idea to
>> mix usage of JTA interface with declarative container managed
>> transacttions for EJBs. In other words it is probably to use Spring
>> JTA helpers/wrappers in web layer which is not using EJB's.
>>
>>   Anyway it would be good have some more advanced tests to ensure
>> that JTA actually work in WLS8 (and other containers) in case of
>> failure/rollback with multiple XA resources involved into transaction
>> (especially resources from different vendors, such as Oracle, Sybase,
>> MQSeries).
>
>
> I fully agree about the tests. This is part of the reason I created
> the ejbtest integration sample. Hopefully we will keep adding to it.
>
> As for the clause in question, it says:
>
> "The EJB container must include the JTA 1.0.1 extension, and it must
> provide the javax.transaction.UserTransaction interface to  enterprise
> beans with bean-managed transaction demarcation through the
> javax.ejb.EJBContext interface, and also in JNDI under the name
> java:comp/UserTransaction, in the cases required by the EJB
> specification.
> The other JTA interfaces are low-level transaction manager and
> resource manager integration interfaces, and are not intended for
> direct use by enterprise beans.
>
> This is unfortunately not worded very well in my opinion, in terms of
> being very clear about CMT. Consider that this is the section of the
> spec called 'The Container Provider's Responsibility'. It is about the
> minimum set of services which the container must provide to the EJB. I
> do not equate anything in the paragraphs above as saying (with any
> adequate level of clarity) that if the container chooses to expose
> other APIs the EJB _is not_ allowed to use them. I read the last
> sentence as a justification as to _why_ the container doesn't have to
> provide the other JTA interfaces. The spec is actually very specific
> about what EJBs may and may not do, consider threading for example.
> Again, my opinion is that if the container does choose to expose an
> API like JTA's TransactionManager, then it has to behave correctly, as
> an API is an API.
>
> Ultimately, only the spec writers know what they really intended, and
> I agree that people wanting to move an app from container to
> container, and from app server version to version, are not going to
> get as predictable results in a CMT+Spring Transaction setup as they
> would in a CMT alone, or Spring Tx alone setup. That said, it can
> still be a viable and useful combination. Over a period of some
> months, I migrated an app on JBoss from CMT EJB to no EJB with Spring
> Tx wrapping service beans, and the CMT+Spring Tx combo provided a
> valuable middle ground in the migration, in the perdio when there were
> still some EJBs, but a lot had already moved over.
>
> Regards,
> Colin
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Abstract bean definitions

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

I've committed the current implementation last night. Feel free to play =
with it :-) We should agree on the final semantics ASAP, to be able to =
release 1.1 final by the end of the week.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Mo 30.08.2004 20:12
An: spr...@li...
Betreff: Re: [Springframework-developer] Abstract bean definitions



Well, getBeansOfType already ignores abstract beans: That method returns =
bean instances, so the only sensible thing to do here is to simply =
ignore abstract beans whose type would match.

getBeanDefinitionNames() and getBeanDefinitionNames(type) do return =
names of abstract beans too, though, just like getBeanDefinitionCount() =
includes abstract beans too. If you cast to =
ConfigurableListableBeanFactory, you can fetch the BeanDefinition for a =
given name, which is also supposed to work for abstract beans - this is =
needed by PropertyPlaceholderConfigurer, for example. So for =
consistency, getBeanDefinitionNames more or less has to return names of =
abstract beans too.

Via ConfigurableListableBeanFactory's getBeanDefinition(name) method, =
you can also check whether a bean definition is abstract now, if you =
absolutely need to. However, I think that for all normal use cases, =
getBeansOfType is what you usually want, as it also checks the type of =
FactoryBeans and returns concrete instances. So I don't think that the =
above is a limitation. And everything's perfectly backwards-compatible =
as long as you don't mark a bean "abstract" anyway...

Regarding public/private beans, there is a problem waiting there too: =
Even private bean definitions need to be visible to =
ConfigurableListableBeanFactory, for PropertyPlaceholderConfigurer and =
co. So should getBeanDefinitionCount and getBeanDefinitionNames include =
private beans too? We could simply check in getBean and getBeansOfType =
to exclude private beans, but that feels a bit odd...

Essentially, do we really need public/private beans now that we have =
abstract beans? getBeansOfType and autowiring by type already exclude =
abstract beans, and inner bean definitions solve the =
TransactionProxyFactoryBean autowiring problem (where both the proxy and =
the target match by type). We should clarify the usage scenarios for =
private beans first, before worrying about them, I guess.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Mo 30.08.2004 19:26
An: spr...@li...
Betreff: Re: [Springframework-developer] Abstract bean definitions



I'll update the docs accordingly.

I agree about making a distinction between getting info for usage by
Spring, and by other users, but the usage semantics with only abstract
and no public/private are a bit problematic. I assume even
   getBeanDefinitionNames(Class type);
and
  getBeansOfType(Class type, boolean includePrototypes, boolean
includeFactoryBeans)
are going to return the abstract beans, right? There is a decent amount
of user code right now which uses these methods to get real live beans.
If abstract beans come in as a result of these calls, and people have no
way to exclude them, it basically precludes using abstract beans for any
bean def hierarchies where somebody is going to be using these methods
to get live beans...

Colin

j=FCrgen h=F6ller [werk3AT] wrote:

>Rod, Colin, everybody,
>
>I've implemented an "abstract" attribute for <bean> tags in XML bean =
definitions. It works as expected in test cases. I've also adapted the =
"baseTxProxy" bean definitions in Petclinic and JPetStore (as introduced =
by Colin) accordingly, marking them as "abstract" rather than =
"lazy-init".
>
>There's one issue with visibility, though: For consistency, an abstract =
bean definition is currently visible just like any other bean =
definition: returned by ListableBeanFactory's getBeanDefinitionNames and =
ConfigurableBeanFactory's getBeanDefinition. On getBean, an =
BeanIsAbstractException gets thrown.
>
>We plan to introduce a "public" attribute for Spring 1.2: This could be =
used to make a bean private, be it abstract or not. IMO, these are =
effectively two separate concerns: I believe that we should treat them =
separately, i.e. not automatically make an abstract bean private.
>
>For example, a bean factory needs to be able to access a parent bean =
definition in an ancestor bean factory, even if that parent bean is =
marked as "abstract" to never get instantiated directly. If an abstract =
parent bean definition were automatically private, this wouldn't work.
>
>What do you think? I'll polish and commit my current implementation =
tonight, if there are no objections. As I said earlier, I'd like to =
release 1.1 final by the end of this week: Abstract bean definitions is =
the last essential feature for that release.
>
>Juergen
>
>




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] JTA transaction suspension on WebSphere

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

This is not an issue for transactions declared with REQUIRED, SUPPORTS, 
MANDATORY or NEVER.  For these transactions there is no need to mess 
with the JTA TransactionManager to suspend the current transaction.  
UserTransaction is sufficient for these and this should be portable 
between containers. 

The only trouble is with REQUIRES_NEW and NOT_SUPPORTED.  Here we have 
to bend the rules and use the JTA TransactionManager API if it is 
available.  This is where things break down since the appservers don't 
seem to cooperate.  Even WebLogic 8.1 did not work until we used a 
WebLogic specific API call (forceResume).

Thomas


Colin Sampaleanu wrote:

> Eugene Kuleshov wrote:
>
>> Colin Sampaleanu wrote:
>>
>>> 'Eu' on his blog 3-4 days ago commented based on my own blog entry, 
>>> and a forum message:
>>>  http://jroller.com/page/eu/20040826#using_spring_jta_interfaces_from
>>> that section / C.2.4 /of the EJB spec says that the container, for 
>>> EJBs, must implement the UserTransaction interface (and JTA 1.0.1) 
>>> extension, but doesn't have to implement the other interfaces 
>>> defined in the JTA specification. Fine, I've actually seen that 
>>> before, coincidentally, when I was tracking something down a while 
>>> ago, but I think a container is fundamentally broken if it _does_ 
>>> expose the JTA TransactionManager interface, and it doesn't behave 
>>> as per the spec. The spec for an API is the spec for the API. If you 
>>> expose the interface at all, then you need to expose it correctly... 
>>> That's essentially how I read that clause, and how I see things. In 
>>> any case, I hope the situation is going to improve, certainly WLS 8 
>>> works where WLS 7 doesn't, with out WL specific adapter...
>>
>>
>>
>>   Perhaps I wasn't clear enough. My point is that it is a bad idea to 
>> mix usage of JTA interface with declarative container managed 
>> transacttions for EJBs. In other words it is probably to use Spring 
>> JTA helpers/wrappers in web layer which is not using EJB's.
>>
>>   Anyway it would be good have some more advanced tests to ensure 
>> that JTA actually work in WLS8 (and other containers) in case of 
>> failure/rollback with multiple XA resources involved into transaction 
>> (especially resources from different vendors, such as Oracle, Sybase, 
>> MQSeries).
>
>
> I fully agree about the tests. This is part of the reason I created 
> the ejbtest integration sample. Hopefully we will keep adding to it.
>
> As for the clause in question, it says:
>
> "The EJB container must include the JTA 1.0.1 extension, and it must 
> provide the javax.transaction.UserTransaction interface to  enterprise 
> beans with bean-managed transaction demarcation through the 
> javax.ejb.EJBContext interface, and also in JNDI under the name 
> java:comp/UserTransaction, in the cases required by the EJB 
> specification.
> The other JTA interfaces are low-level transaction manager and 
> resource manager integration interfaces, and are not intended for 
> direct use by enterprise beans.
>
> This is unfortunately not worded very well in my opinion, in terms of 
> being very clear about CMT. Consider that this is the section of the 
> spec called 'The Container Provider's Responsibility'. It is about the 
> minimum set of services which the container must provide to the EJB. I 
> do not equate anything in the paragraphs above as saying (with any 
> adequate level of clarity) that if the container chooses to expose 
> other APIs the EJB _is not_ allowed to use them. I read the last 
> sentence as a justification as to _why_ the container doesn't have to 
> provide the other JTA interfaces. The spec is actually very specific 
> about what EJBs may and may not do, consider threading for example. 
> Again, my opinion is that if the container does choose to expose an 
> API like JTA's TransactionManager, then it has to behave correctly, as 
> an API is an API.
>
> Ultimately, only the spec writers know what they really intended, and 
> I agree that people wanting to move an app from container to 
> container, and from app server version to version, are not going to 
> get as predictable results in a CMT+Spring Transaction setup as they 
> would in a CMT alone, or Spring Tx alone setup. That said, it can 
> still be a viable and useful combination. Over a period of some 
> months, I migrated an app on JBoss from CMT EJB to no EJB with Spring 
> Tx wrapping service beans, and the CMT+Spring Tx combo provided a 
> valuable middle ground in the migration, in the perdio when there were 
> still some EJBs, but a lot had already moved over.
>
> Regards,
> Colin
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>

Re: [Springframework-developer] JTA transaction suspension on WebSphere

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

Eugene Kuleshov wrote:

> Colin Sampaleanu wrote:
>
>> 'Eu' on his blog 3-4 days ago commented based on my own blog entry, 
>> and a forum message:
>>  http://jroller.com/page/eu/20040826#using_spring_jta_interfaces_from
>> that section / C.2.4 /of the EJB spec says that the container, for 
>> EJBs, must implement the UserTransaction interface (and JTA 1.0.1) 
>> extension, but doesn't have to implement the other interfaces defined 
>> in the JTA specification. Fine, I've actually seen that before, 
>> coincidentally, when I was tracking something down a while ago, but I 
>> think a container is fundamentally broken if it _does_ expose the JTA 
>> TransactionManager interface, and it doesn't behave as per the spec. 
>> The spec for an API is the spec for the API. If you expose the 
>> interface at all, then you need to expose it correctly... That's 
>> essentially how I read that clause, and how I see things. In any 
>> case, I hope the situation is going to improve, certainly WLS 8 works 
>> where WLS 7 doesn't, with out WL specific adapter...
>
>
>   Perhaps I wasn't clear enough. My point is that it is a bad idea to 
> mix usage of JTA interface with declarative container managed 
> transacttions for EJBs. In other words it is probably to use Spring 
> JTA helpers/wrappers in web layer which is not using EJB's.
>
>   Anyway it would be good have some more advanced tests to ensure that 
> JTA actually work in WLS8 (and other containers) in case of 
> failure/rollback with multiple XA resources involved into transaction 
> (especially resources from different vendors, such as Oracle, Sybase, 
> MQSeries).

I fully agree about the tests. This is part of the reason I created the 
ejbtest integration sample. Hopefully we will keep adding to it.

As for the clause in question, it says:

"The EJB container must include the JTA 1.0.1 extension, and it must 
provide the javax.transaction.UserTransaction interface to  enterprise 
beans with bean-managed transaction demarcation through the 
javax.ejb.EJBContext interface, and also in JNDI under the name 
java:comp/UserTransaction, in the cases required by the EJB specification.
The other JTA interfaces are low-level transaction manager and resource 
manager integration interfaces, and are not intended for direct use by 
enterprise beans.

This is unfortunately not worded very well in my opinion, in terms of 
being very clear about CMT. Consider that this is the section of the 
spec called 'The Container Provider's Responsibility'. It is about the 
minimum set of services which the container must provide to the EJB. I 
do not equate anything in the paragraphs above as saying (with any 
adequate level of clarity) that if the container chooses to expose other 
APIs the EJB _is not_ allowed to use them. I read the last sentence as a 
justification as to _why_ the container doesn't have to provide the 
other JTA interfaces. The spec is actually very specific about what EJBs 
may and may not do, consider threading for example. Again, my opinion is 
that if the container does choose to expose an API like JTA's 
TransactionManager, then it has to behave correctly, as an API is an API.

Ultimately, only the spec writers know what they really intended, and I 
agree that people wanting to move an app from container to container, 
and from app server version to version, are not going to get as 
predictable results in a CMT+Spring Transaction setup as they would in a 
CMT alone, or Spring Tx alone setup. That said, it can still be a viable 
and useful combination. Over a period of some months, I migrated an app 
on JBoss from CMT EJB to no EJB with Spring Tx wrapping service beans, 
and the CMT+Spring Tx combo provided a valuable middle ground in the 
migration, in the perdio when there were still some EJBs, but a lot had 
already moved over.

Regards,
Colin

Re: [Springframework-developer] jsp tags

[Daniel M. <mi...@pa...>]

I'm almost finished with them :)

~ Daniel Miller

bobmanc wrote:

> What is the status on the input tags for jsp? They are going to make it into 1.2
> final I hope.
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 

[Springframework-developer] Spring AOP on java-source.net

[katentim @hotmail.c. <kat...@ho...>]

Noticed Spring is missing from:
http://java-source.net/open-source/aspect-oriented-frameworks

Adding it requires providing a description. I thought I should leave that to 
a core developer. Below is what I would have added from reference docs, but 
you may want to read through the other AOP descriptions to highlight 
differentiators.

Spring allow users to implement custom aspects, complementing their use of 
OOP with AOP.

AOP is used in Spring to provide declarative enterprise services, especially 
as a replacement for EJB declarative services. The most important such 
service is declarative transaction management, which builds on Spring's 
transaction abstraction.

As of 1.1, Spring provides a powerful integration with AspectJ.

_________________________________________________________________
All only $4! Get the latest mobile tones, images and logos:   
http://fun.mobiledownloads.com.au/191191/index.wl