springframework-developer — Spring Framework developers list

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

[Eugene K. <eu...@pl...>]

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).

   regards,
   Eugene


> Colin
> 
> jürgen höller [werk3AT] wrote:
> 
>> After our recent issues with JTA resume (with the outer transaction 
>> marked as rollback-only) on WebLogic, which we were just able to solve 
>> for WebLogic 8.1 but not for 7.0:
>>
>> http://opensource.atlassian.com/projects/spring/browse/SPR-251 
>> <http://opensource.atlassian.com/projects/spring/browse/SPR-251>
>> we now have similar problems on WebSphere 4.0, seemingly with 
>> suspension of an ordinary transaction:
>>
>> http://opensource.atlassian.com/projects/spring/browse/SPR-295 
>> <http://opensource.atlassian.com/projects/spring/browse/SPR-295>
>> Any WebSphere user that can shed some light on this? I'm afraid that 
>> we'll have to invoke some proprietary WebSphere API for JTA 
>> suspend/resume, just like we had to do for WebLogic...
>>
>> Oh how do I wish that J2EE considered 
>> javax.transaction.TransactionManager as proper public API...
>>
>> 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] JTA transaction suspension on WebSphere

[Eugene K. <eu...@pl...>]

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).

   regards,
   Eugene


> Colin
> 
> jürgen höller [werk3AT] wrote:
> 
>> After our recent issues with JTA resume (with the outer transaction 
>> marked as rollback-only) on WebLogic, which we were just able to solve 
>> for WebLogic 8.1 but not for 7.0:
>>
>> http://opensource.atlassian.com/projects/spring/browse/SPR-251 
>> <http://opensource.atlassian.com/projects/spring/browse/SPR-251>
>> we now have similar problems on WebSphere 4.0, seemingly with 
>> suspension of an ordinary transaction:
>>
>> http://opensource.atlassian.com/projects/spring/browse/SPR-295 
>> <http://opensource.atlassian.com/projects/spring/browse/SPR-295>
>> Any WebSphere user that can shed some light on this? I'm afraid that 
>> we'll have to invoke some proprietary WebSphere API for JTA 
>> suspend/resume, just like we had to do for WebLogic...
>>
>> Oh how do I wish that J2EE considered 
>> javax.transaction.TransactionManager as proper public API...
>>
>> 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] JTA transaction suspension on WebSphere

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

'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...

Colin

jürgen höller [werk3AT] wrote:

>After our recent issues with JTA resume (with the outer transaction marked as rollback-only) on WebLogic, which we were just able to solve for WebLogic 8.1 but not for 7.0:
> 
>http://opensource.atlassian.com/projects/spring/browse/SPR-251 <http://opensource.atlassian.com/projects/spring/browse/SPR-251> 
> 
>we now have similar problems on WebSphere 4.0, seemingly with suspension of an ordinary transaction:
> 
>http://opensource.atlassian.com/projects/spring/browse/SPR-295 <http://opensource.atlassian.com/projects/spring/browse/SPR-295> 
> 
>Any WebSphere user that can shed some light on this? I'm afraid that we'll have to invoke some proprietary WebSphere API for JTA suspend/resume, just like we had to do for WebLogic...
> 
>Oh how do I wish that J2EE considered javax.transaction.TransactionManager as proper public API...
> 
>Juergen
> 
>  
>

[Springframework-developer] JTA transaction suspension on WebSphere

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

After our recent issues with JTA resume (with the outer transaction =
marked as rollback-only) on WebLogic, which we were just able to solve =
for WebLogic 8.1 but not for 7.0:
=20
http://opensource.atlassian.com/projects/spring/browse/SPR-251 =
<http://opensource.atlassian.com/projects/spring/browse/SPR-251>=20
=20
we now have similar problems on WebSphere 4.0, seemingly with suspension =
of an ordinary transaction:
=20
http://opensource.atlassian.com/projects/spring/browse/SPR-295 =
<http://opensource.atlassian.com/projects/spring/browse/SPR-295>=20
=20
Any WebSphere user that can shed some light on this? I'm afraid that =
we'll have to invoke some proprietary WebSphere API for JTA =
suspend/resume, just like we had to do for WebLogic...
=20
Oh how do I wish that J2EE considered =
javax.transaction.TransactionManager as proper public API...
=20
Juergen
=20

Re: [Springframework-developer] Abstract bean definitions

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

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.
=20
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.
=20
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...
=20
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...
=20
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.
=20
Juergen
=20

________________________________

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
>=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] Abstract bean definitions

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

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ürgen höller [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
>  
>

[Springframework-developer] jsp tags

[bobmanc <bo...@ex...>]

What is the status on the input tags for jsp? They are going to make it into 1.2
final I hope.

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

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

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

I'll update the ejbtest integration test/sample at a minimum to test=20
some of the new options. I should be able to update the ejb docs to=20
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.
>=20
>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").
>=20
>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.
>=20
>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?
>=20
>Juergen
>=20
>
>________________________________
>
>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

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

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

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


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

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

[Springframework-developer] Abstract bean definitions

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

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

[Springframework-developer] Re: <property><value>

[Steve H. <sh...@at...>]

On 2004-08-27, Rod Johnson <ro...@in...> wrote:
> Steve
>
> The first version of the DTD (with the Interface21 framework that preceded
> Spring) used the simpler form you suggest.  We moved away from it because it
> was hard to support references etc. cleanly without a nested element for
> value or alternatives.

I see.  I had suspected it had to do with the implementation of the parser,
so I made the change to see how it would work out.  It turned out to be just
a few lines of code inside DefaultXmlBeanDefinitionParser::getPropertyValue(),
and all existing tests still pass:

480,484d479
< if (valueRefOrCollectionElement == null && nl.getLength() > 0) {
<      if (nl.item(0).getNodeType() == Node.TEXT_NODE) {
<          return getTextValue(ele, beanName).trim();
<      }
< }

and in spring-beans.dtd:

<!ELEMENT property ANY>

> I agree that line length can be an issue, but finger typing should never be
> an issue: use XMLBuddy or the like. I haven't typed a Spring XML tag for
> months.

Right, it's not really about ease of creating the files, its more a matter
of reducing visual clutter so as to make the files easier to read (I'm thinking
primarily of files created by others, sample code, documentation, etc.)

Consider:

<property name="password">secret</property>
vs.
<property name="password"><value>secret</value></property>

The first case puts "secret" right next to "password", so it's very easy
to tell what is going on with a quick glance.  The <value> tag in
the second case is just redundant (text inside an xml element is of
course the element's value by definition).

I think it's analagous to using unnecessary casts in Java code -

String s = (String) (new String());
vs.
String s = new String();

Steve

[Springframework-developer] spring build.90 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.90</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build:&nbsp;</span>08/30/2004 00:17:06</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>13 minutes 31 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed:&nbsp;</span>08/29/2004 05:55:24</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try:&nbsp;</span>add equals and hashCode 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;               =
     (2)                </td></tr><tr class=3D"modifications-evenrow"><td c=
lass=3D"modifications-data">modified</td><td class=3D"modifications-data">c=
olins</td><td class=3D"modifications-data">src/org/springframework/transact=
ion/interceptor/NoRollbackRuleAttribute.java</td><td class=3D"modifications=
-data">add equals and hashCode methods</td></tr><tr class=3D"modifications-=
oddrow"><td class=3D"modifications-data">modified</td><td class=3D"modifica=
tions-data">colins</td><td class=3D"modifications-data">src/org/springframe=
work/transaction/interceptor/RollbackRuleAttribute.java</td><td class=3D"mo=
difications-data">add equals and hashCode methods</td></tr></table><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] Re: Hibernate 3

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

Completely agree with Juergen. Hibernate2 is used much more widely than
Hibernate1, IMO, so will take a lot longer to disappear.

I don't like the idea of breaking existing package names. After all, the
Hibernate developers have chosen to abandon backward compatibility--we =
can't
do a miracle and hide that in Spring.=20

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: 25 August 2004 08:14
To: spr...@li...
Subject: Re: [Springframework-developer] Re: Hibernate 3

We do certainly not intend to drop Hibernate2 any time soon: It's too
ubiquitous, and will be for some time to come. BTW, we also support both
iBATIS SQL Maps 1.3.1 and 2.0: There, we have two different APIs in
different iBATIS packages, so both reside in our "orm.ibatis" package.
=20
>From my point of view, let's simply create a new "orm.hibernate3" =
package,
and keep the old "orm.hibernate" package as-is for Hibernate 2.1. While
renaming the old package might seem appropriate in terms of consistently
applying the Hibernate version number, I don't believe it adds much =
value:
If it's still called "hibernate", we can simply point out that it refers =
to
classic Hibernate, i.e. 2.1. That gives us full backwards compatibility,
just with add-on support for Hibernate3.
=20
Finally, Hibernate3 is still alpha. I'm quite strongly against shipping
support classes for alpha software, particularly if it's such a large =
bunch
as for Hibernate3. We can certainly add such classes as "orm.hibernate3"
package to the sandbox, but they should remain there until there's at =
least
a beta release out.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von
Martin Kersten
Gesendet: Mi 25.08.2004 04:18
An: spr...@li...
Betreff: Re: [Springframework-developer] Re: Hibernate 3



> I think Spring 1.XX should always work with Hibernate 2.  A Spring=20
> 2.XX release could drop Hibernate 2, IMHO.  But that is a far bit=20
> away.

I don't like droping Hibernate 2. You know it will cost some afford (aka
money) to convert a project utilizing Hibernate2 to a project utilizing
Hibernate3. So it is very likely to have projects, which work fine and =
using
Hibernate 2 to stay in that condition for a really long time. And so I =
think
the support should not be dropped anytime. At least a compatible =
solution
should be offered.

I favour the package naming solution, mentioned earlier. Call the =
package
hibernate3 and rename the old one to hibernate2.

So I guess things would become very clear and beside some renaming =
nothing
much has to be changed to convert an existing project to use the newest
Spring release.


Cheers,

Martin (Kersten)

>
> Minor release numbers should always be backwards compatible.
>
> My two cents,
> Seth
>
> On Tue, 24 Aug 2004 12:55:36 -0500, Tom K <tk...@co...> wrote:
> > I second this (anyone else?). Hibernate3 will be what I develop my=20
> > new projects with.
> >
> > Tom K.
> >
> >
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On=20
> > Behalf Of Artur Karazniewicz
> > Sent: Tuesday, August 24, 2004 12:48 PM
> > To: spr...@li...
> > Subject: [Springframework-developer] Re: Hibernate 3
> >
> > Colin Sampaleanu wrote:
> >
> > > Hibernate 3 is now out in Alpha. We should probably start thinking
> > about
> > > how to add support for it, and a timeframe.
> >
> > It would be great to have HB3 incorporated into spring, even in =
sandbox.
> > Lot
> > of people could possibly help testing HB3 (well, at leas me:). Of=20
> > course
> > HB3 has a lot of new, shiny, sexy features :).
> >
> > > It's actually good that we didn't do anything before this, as=20
> > > there
> > have
> > > been 4-5 bug fixes in Hibernate related session handling and
> > transaction
> > > code the last few weeks. Since Hibernate 3 is in an entirely=20
> > > different package, what I think is probably the only viable option =

> > > given that people are going to be using Hibernate2 for a long time =

> > > yet, is to
> > build
> > > up a parallel hierarchy of the support classes, probably with the=20
> > > same package names, but 'hibernate3' instead of just 'hibernate'.=20
> > > Arguably, the class names might make sense to have the version=20
> > > too, since it
> > would
> > > reduce confusion a lot.
> >
> > I'm not convinced. I thing most developers will switch from 2 to 3=20
> > within a year. After that HB2 will be virtually outdated (like HB1=20
> > is now) and spring will end up with "polluted" package names. I tend =

> > to wait few months and switch completly to HB3, instead of HB2 and=20
> > not "polluting" spring packages. What about using "old"=20
> > *.hibernate.* packages and adding classes with version suffix? Just=20
> > my $0.02. (and of course, with CVS there are, unfortunatelly serious =

> > problems with directories - so refactoring (future
> > hibernate3->hibernate migration) is rather hard, in this case).
> >
> > > In terms of a timeframe, this could happen at any time in the=20
> > > sandbox, and probably in the main source tree after 1.1 final is=20
> > > out. The main issue is developer time, although I see the work as=20
> > > being pretty straightforward to do a direct translation. It's=20
> > > definitely worth it
> > to
> > > then figure out what makes sense to add given the enhanced
> > capabilities.
> > >
> > > One interesting thing I read in the release notes; Hibernate now
> > throws
> > > unchecked exceptions instead of checked exceptions...
> >
> > Other which could reflect spring API are "named-entities". All "old"
> > session
> > - entity related - methods are now doubled with new, overloaded=20
> > versions with entity name.
> >
> > Having support for new hibernate - spring managed - events would be=20
> > cool also.
> >
> > Artur
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank=20
> > Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only=20
> > $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free =
Gift.
> > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> > _______________________________________________
> > Springframework-developer mailing list=20
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-develop
> > er
> >
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.740 / Virus Database: 494 - Release Date: 8/16/2004
> >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.740 / Virus Database: 494 - Release Date: 8/16/2004
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank=20
> > Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only=20
> > $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free =
Gift.
> > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> > _______________________________________________
> > Springframework-developer mailing list=20
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-develop
> > er
> >
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media =

> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save =

> 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media =
100pk
Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off
Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media =
100pk
Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off
Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
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 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
>>    
>>

Re: [Springframework-developer] JIRA has been down for a while

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

Now that was a quick response :-) Many thanks, Matthew!
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Matthew E. Porter
Gesendet: So 29.08.2004 17:09
An: spr...@li...
Betreff: Re: [Springframework-developer] JIRA has been down for a while



It's up.


Cheers,
   Matthew


On Aug 29, 2004, at 10:00 AM, j=FCrgen h=F6ller [werk3AT] wrote:

> I noticed that too. Let's contact Mike promptly: We absolutely need
> JIRA to prepare for 1.1 final.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag
> von Colin Sampaleanu
> Gesendet: So 29.08.2004 15:13
> An: spr...@li...
> Betreff: [Springframework-developer] JIRA has been down for a while
>
>
>
> I ahven't been able to access it for at least 12-18 hours. It's a
> shared
> instance, so I presume Atlassian knows about it, but maybe we should
> contact them. Mike is our contact?
>
> 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_idP47&alloc_id=10808&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] JIRA has been down for a while

[Matthew E. P. <mat...@me...>]

It's up.


Cheers,
   Matthew


On Aug 29, 2004, at 10:00 AM, j=FCrgen h=F6ller [werk3AT] wrote:

> I noticed that too. Let's contact Mike promptly: We absolutely need=20
> JIRA to prepare for 1.1 final.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag=20=

> von Colin Sampaleanu
> Gesendet: So 29.08.2004 15:13
> An: spr...@li...
> Betreff: [Springframework-developer] JIRA has been down for a while
>
>
>
> I ahven't been able to access it for at least 12-18 hours. It's a=20
> shared
> instance, so I presume Atlassian knows about it, but maybe we should
> contact them. Mike is our contact?
>
> 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_idP47&alloc_id=10808&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] JIRA has been down for a while

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

I noticed that too. Let's contact Mike promptly: We absolutely need JIRA =
to prepare for 1.1 final.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: So 29.08.2004 15:13
An: spr...@li...
Betreff: [Springframework-developer] JIRA has been down for a while



I ahven't been able to access it for at least 12-18 hours. It's a shared
instance, so I presume Atlassian knows about it, but maybe we should
contact them. Mike is our contact?

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

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

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

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.
=20
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").
=20
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.
=20
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?
=20
Juergen
=20

________________________________

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:

>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
>
>




-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
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] JNDI object caching and AbstractJndiLocator

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

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.
=20
* 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".
=20
* 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.
=20
* 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.
=20
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.
=20
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.
=20
Juergen
=20


________________________________

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:

>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
>
>




-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Spring-JPOX tutorial

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

Following up on
http://forum.springframework.org/viewtopic.php?t=3D195
=20
I guess it's appropriate to link to=20
http://www.jpox.org/docs/1_1/tutorials/springframework.html
from the demo/tutorial page of springframework.org.
=20
The number of Spring-JDO sample applications is growing :-)
Now we just need to write a comprehensive JDO support section for our =
reference manual...
=20
Juergen

[Springframework-developer] JIRA has been down for a while

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

I ahven't been able to access it for at least 12-18 hours. It's a shared 
instance, so I presume Atlassian knows about it, but maybe we should 
contact them. Mike is our contact?

Colin

[Springframework-developer] spring build.89 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.89</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build:&nbsp;</span>08/29/2004 00:16:40</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>13 minutes 36 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed:&nbsp;</span>08/28/2004 14:20:55</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try:&nbsp;</span>Slight error in MVC doco, fixed</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;               =
     (11)                </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/mvc.xml</=
td><td class=3D"modifications-data">Slight error in MVC doco, fixed</td></t=
r><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">modif=
ied</td><td class=3D"modifications-data">aarendsen</td><td class=3D"modific=
ations-data">docs/reference/src/mvc.xml</td><td class=3D"modifications-data=
">Enhanced view resolving doco a bit</td></tr><tr class=3D"modifications-ev=
enrow"><td class=3D"modifications-data">modified</td><td class=3D"modificat=
ions-data">kdonald</td><td class=3D"modifications-data">sandbox/src/org/spr=
ingframework/rules/values/BufferedValueModel.java</td><td class=3D"modifica=
tions-data">buffered model now tracks commit status</td></tr><tr class=3D"m=
odifications-oddrow"><td class=3D"modifications-data">modified</td><td clas=
s=3D"modifications-data">kdonald</td><td class=3D"modifications-data">sandb=
ox/src/org/springframework/rules/values/BufferedValueModel.java</td><td cla=
ss=3D"modifications-data">buffered model now tracks commit status</td></tr>=
<tr class=3D"modifications-evenrow"><td class=3D"modifications-data">modifi=
ed</td><td class=3D"modifications-data">kdonald</td><td class=3D"modificati=
ons-data">sandbox/src/org/springframework/rules/values/BeanPropertyAccessSt=
rategy.java</td><td class=3D"modifications-data">bug fixes for nested prope=
rty accessors - property access strategiesnow cache property adapters</td><=
/tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">mod=
ified</td><td class=3D"modifications-data">kdonald</td><td class=3D"modific=
ations-data">sandbox/src/org/springframework/rules/values/BeanPropertyAcces=
sStrategy.java</td><td class=3D"modifications-data">bug fixes for nested pr=
operty accessors - property access strategiesnow cache property adapters</t=
d></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-data"=
>modified</td><td class=3D"modifications-data">kdonald</td><td class=3D"mod=
ifications-data">sandbox/src/org/springframework/rules/values/PropertyAdapt=
er.java</td><td class=3D"modifications-data">bug fixes for nested property =
accessors - property access strategiesnow cache property adapters</td></tr>=
<tr class=3D"modifications-oddrow"><td class=3D"modifications-data">modifie=
d</td><td class=3D"modifications-data">kdonald</td><td class=3D"modificatio=
ns-data">sandbox/src/org/springframework/rules/values/ValueHolder.java</td>=
<td class=3D"modifications-data">bug fixes for nested property accessors - =
property access strategiesnow cache property adapters</td></tr><tr class=3D=
"modifications-evenrow"><td class=3D"modifications-data">modified</td><td c=
lass=3D"modifications-data">kdonald</td><td class=3D"modifications-data">sa=
ndbox/src/org/springframework/rules/values/BeanPropertyAccessStrategy.java<=
/td><td class=3D"modifications-data">bug fixes for nested property accessor=
s - property access strategiesnow cache property adapters</td></tr><tr clas=
s=3D"modifications-oddrow"><td class=3D"modifications-data">modified</td><t=
d class=3D"modifications-data">kdonald</td><td class=3D"modifications-data"=
>sandbox/src/org/springframework/rules/values/DefaultFormModel.java</td><td=
 class=3D"modifications-data">bug fixes for nested property accessors - pro=
perty access strategiesnow cache property adapters</td></tr><tr class=3D"mo=
difications-evenrow"><td class=3D"modifications-data">modified</td><td clas=
s=3D"modifications-data">kdonald</td><td class=3D"modifications-data">sandb=
ox/src/org/springframework/rules/values/MutablePropertyAccessStrategy.java<=
/td><td class=3D"modifications-data">bug fixes for nested property accessor=
s - property access strategiesnow cache property adapters</td></tr></table>=
<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>

[Springframework-developer] Resource param descriptions

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

I think we need to be a bit clearer when documenting API params which 
take Resource types. My feeling is that many if not most Spring users 
don't really realize that the ResourceEditor PropertyEditor mechanism 
which takes their String path and produces a resource for the param is 
actually going to give them different results for paths used inside a 
web AppContext variant as opposed to the other AppContext types. 
Actually my gut feel is that for some Spring users at least, the whole 
way Resources are resolved is a bit of magic, and they don't even fully 
understand the Resource types, or know the default ResourceEditor 
PropertyEditor exists...

In the case of SqlMapClientFactoryBean for example, the configLocation 
param, which is a Resource, is just described as
   'Set the location of the iBATIS SqlMapClient config file as class 
path resource. A typical value is "WEB-INF/sql-map-config.xml"'.

This is actually pretty wrong. It's setting it as a Resource, which is 
not necessarilly a classpath resource. The typical value described will 
in fact only work inside a web ApplicationContext variant (it should 
also really have a leading slash for the example, although Spring will 
add that if necessary).

Here's a link to a forum thread where a user ran into some confusion 
related to this:
  http://forum.springframework.org/viewtopic.php?p=1761

I'm going to try to track down params like this and document them a bit 
better...

Regards,
Colin

[Springframework-developer] spring build.88 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.88</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build:&nbsp;</span>08/28/2004 00:17:07</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>13 minutes 40 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed:&nbsp;</span>08/27/2004 14:51:25</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try:&nbsp;</span>remote exception handling, remote proxy caching/refreshing=
</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;               =
     (26)                </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">/changelog.txt</td><td class=
=3D"modifications-data">remote exception handling, remote proxy caching/ref=
reshing</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modificati=
ons-data">modified</td><td class=3D"modifications-data">jhoeller</td><td cl=
ass=3D"modifications-data">test/org/springframework/ejb/access/SimpleRemote=
SlsbInvokerInterceptorTests.java</td><td class=3D"modifications-data">rewor=
ked exception handling, added configurable proxy caching/refreshing</td></t=
r><tr class=3D"modifications-evenrow"><td class=3D"modifications-data">modi=
fied</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modific=
ations-data">test/org/springframework/remoting/RemotingTestSuite.java</td><=
td class=3D"modifications-data">reworked exception handling, added configur=
able proxy caching/refreshing</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/remot=
ing/RemoteConnectFailureException.java</td><td class=3D"modifications-data"=
>reworked exception handling, added configurable proxy caching/refreshing</=
td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-data=
">added</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modi=
fications-data">src/org/springframework/remoting/RemoteLookupFailureExcepti=
on.java</td><td class=3D"modifications-data">reworked exception handling, a=
dded configurable proxy caching/refreshing</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/remoting/support/RemoteInvocation.java</td><td class=3D"modifica=
tions-data">reworked exception handling, added configurable proxy caching/r=
efreshing</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modific=
ations-data">modified</td><td class=3D"modifications-data">jhoeller</td><td=
 class=3D"modifications-data">test/org/springframework/ejb/access/LocalSlsb=
InvokerInterceptorTests.java</td><td class=3D"modifications-data">reworked =
exception handling, added configurable proxy caching/refreshing</td></tr><t=
r class=3D"modifications-oddrow"><td class=3D"modifications-data">modified<=
/td><td class=3D"modifications-data">jhoeller</td><td class=3D"modification=
s-data">src/org/springframework/remoting/caucho/HessianClientInterceptor.ja=
va</td><td class=3D"modifications-data">reworked exception handling, added =
configurable proxy caching/refreshing</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/remoting/rmi/JndiRmiClientInterceptor.java</td><td class=3D"modifica=
tions-data">reworked exception handling, added configurable proxy caching/r=
efreshing</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifica=
tions-data">modified</td><td class=3D"modifications-data">jhoeller</td><td =
class=3D"modifications-data">src/org/springframework/remoting/rmi/RmiClient=
Interceptor.java</td><td class=3D"modifications-data">reworked exception ha=
ndling, added configurable proxy caching/refreshing</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/remoting/rmi/RmiClientInterceptorUtils.java</td><td cl=
ass=3D"modifications-data">reworked exception handling, added configurable =
proxy caching/refreshing</td></tr><tr class=3D"modifications-oddrow"><td cl=
ass=3D"modifications-data">modified</td><td class=3D"modifications-data">jh=
oeller</td><td class=3D"modifications-data">src/org/springframework/ejb/acc=
ess/AbstractRemoteSlsbInvokerInterceptor.java</td><td class=3D"modification=
s-data">reworked exception handling, added configurable proxy caching/refre=
shing</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modificatio=
ns-data">modified</td><td class=3D"modifications-data">jhoeller</td><td cla=
ss=3D"modifications-data">src/org/springframework/ejb/access/AbstractSlsbIn=
vokerInterceptor.java</td><td class=3D"modifications-data">reworked excepti=
on handling, added configurable proxy caching/refreshing</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/ejb/access/LocalSlsbInvokerInterceptor.java</td><t=
d class=3D"modifications-data">reworked exception handling, added configura=
ble proxy caching/refreshing</td></tr><tr class=3D"modifications-evenrow"><=
td class=3D"modifications-data">modified</td><td class=3D"modifications-dat=
a">jhoeller</td><td class=3D"modifications-data">src/org/springframework/ej=
b/access/LocalStatelessSessionProxyFactoryBean.java</td><td class=3D"modifi=
cations-data">reworked exception handling, added configurable proxy caching=
/refreshing</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/ejb/access/SimpleRem=
oteSlsbInvokerInterceptor.java</td><td class=3D"modifications-data">reworke=
d exception handling, added configurable proxy caching/refreshing</td></tr>=
<tr class=3D"modifications-evenrow"><td class=3D"modifications-data">modifi=
ed</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modificat=
ions-data">src/org/springframework/ejb/access/SimpleRemoteStatelessSessionP=
roxyFactoryBean.java</td><td class=3D"modifications-data">reworked exceptio=
n handling, added configurable proxy caching/refreshing</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/remoting/caucho/BurlapClientInterceptor.java</td><=
td class=3D"modifications-data">reworked exception handling, added configur=
able proxy caching/refreshing</td></tr><tr class=3D"modifications-evenrow">=
<td class=3D"modifications-data">added</td><td class=3D"modifications-data"=
>jhoeller</td><td class=3D"modifications-data">src/org/springframework/jndi=
/JndiObjectTargetSource.java</td><td class=3D"modifications-data">added Jnd=
iObjectTargetSource</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/jndi/Abstr=
actJndiLocator.java</td><td class=3D"modifications-data">deprecated Abstrac=
tJndiLocator base class in favor of new JndiObjectLocator</td></tr><tr clas=
s=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td><=
td class=3D"modifications-data">jhoeller</td><td class=3D"modifications-dat=
a">src/org/springframework/jndi/JndiObjectFactoryBean.java</td><td class=3D=
"modifications-data">deprecated AbstractJndiLocator base class in favor of =
new JndiObjectLocator</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/jndi/JndiObje=
ctLocator.java</td><td class=3D"modifications-data">deprecated AbstractJndi=
Locator base class in favor of new JndiObjectLocator</td></tr><tr class=3D"=
modifications-evenrow"><td class=3D"modifications-data">modified</td><td cl=
ass=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">sr=
c/org/springframework/web/struts/ActionSupport.java</td><td class=3D"modifi=
cations-data">added LookupDispatchActionSupport</td></tr><tr class=3D"modif=
ications-oddrow"><td class=3D"modifications-data">modified</td><td class=3D=
"modifications-data">jhoeller</td><td class=3D"modifications-data">src/org/=
springframework/web/struts/DispatchActionSupport.java</td><td class=3D"modi=
fications-data">added LookupDispatchActionSupport</td></tr><tr class=3D"mod=
ifications-evenrow"><td class=3D"modifications-data">added</td><td class=3D=
"modifications-data">jhoeller</td><td class=3D"modifications-data">src/org/=
springframework/web/struts/LookupDispatchActionSupport.java</td><td class=
=3D"modifications-data">added LookupDispatchActionSupport</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=
">test/org/springframework/web/struts/StrutsSupportTests.java</td><td class=
=3D"modifications-data">added LookupDispatchActionSupport</td></tr></table>=
<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>

[Springframework-developer] Specify BeanID as class variable reference

[KIR <kir...@gm...>]

Hi,

   I'd like to discuss a feature when beanID is specified in a form
   path.to.bean.interface.ID . 

  This allows to avoid duplication of strings between xml and Java
code and allows to rename these id easily. I've opened corresponding
request in Jira:
 
http://opensource.atlassian.com/projects/spring/browse/SPR-289

 Any thoughts?

-- 
Kirill Maximov (aka KIR) | http://www.maxkir.com