springframework-developer — Spring Framework developers list

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

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

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

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Mi 25.08.2004 09:33
An: spr...@li...
Betreff: Re: [Springframework-developer] JNDI object caching and =
AbstractJndiLocator



I've actually changed AbstractJndiLocator's internal workings: =
Subclasses are supposed to explicitly call a "lookup()" method now, =
receiving the freshly located object, rather than getting a =
"located(Object)" callback on startup. This is necessary to implement =
true hot fetching of the JNDI object (just in time for calling a method =
on it, and throwing it away again right afterwards), without temporarily =
storing it in an instance variable.

In terms of backwards compatibility, it's probably better to keep the =
AbstractJndiLocator as-is (deprecating it though) and put the new code =
into a JndiObjectLocator base class. Our remoting proxies can then =
derive from that new base class, with explicit lookup calls whenever =
they need them.

There's actually four strategies that we could support out-of-the-box:
1. look up the JNDI object on bean initialization, storing it for later =
usage
2. look up the JNDI object on bean initialization (to determine =
interfaces or for validation), refetching it for every operation
3. look up the JNDI object on first need (first call to =
JndiObjectLocator.lookup), storing it for later usage
4. look up the JNDI object for every operation (every call to =
JndiObjectLocator.lookup)

Number 1 is current standard behavior. Number 3 requires synchronized =
access to the stored JNDI object, but seems to be the appropriate =
behavior for EJB lookups (avoiding lazy-init on the bean and all objects =
that depend on it). Number 4 allows hot-redeploy of EJBs, mainly during =
development; number 2 does the same, but performs early validation, =
assuming that the lookup already works on startup.

Regarding usage of remote EJB homes: What alternative strategies are =
there for our SimpleRemoteSlsbInvokerInterceptor, i.e. what could you do =
more efficiently if you accept some assumptions about your server? I =
could imagine that on some servers, creating the SLSB instance once and =
keeping it for the lifetime of the client application would work: Often, =
the SLSB instance is just a proxy that creates new calls to the servers =
every time, not allocating any resources on the server...

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Di 24.08.2004 21:01
An: spr...@li...
Betreff: Re: [Springframework-developer] JNDI object caching and =
AbstractJndiLocator



I don't think it's a big deal if AbstractJndiLocator doesn't do an
immediate lookup on initialization. I actually complained about the fact
that it did this a while ago, and this is why most people are
recommended to make their EJB proxies lazy, since a lot of the time the
JNDI tree is not ready at the time the JNDI lookup is done, if the proxy
is not set as ready, depending on the EJB environment. I would be
surprised if too many people are using this class, as opposed to
JndiObjectFactoryBean... Is this the only thing you want to change in
AbstractJndiLocator?

As for the question about remote communication on the usage of the home,
I don't think there's any guarantees here. A clustering EJB
implementation could very well do some remote communication on create
calls, if that makes the job of the cluster management code easier. It
is typically the bean stub itself that handles cluster failover, so I
dont think the home object actually has any real need to do remote
communications, but I don't remember there being any contract forbidding
it. I'm working from memory, but I do seem to remember that EJB 2.0 does
recommend that you now stay in your own VM, when creating a new stub,
for efficiency reasons. I.e. load balancing is no longer supposed to be
handled by automatically (by default) handing off to EJBs on different
cluster members, with that being recommended only for failover.

Colin

j=FCrgen h=F6ller [werk3AT] wrote:

>I've just checked remote proxy caching throughout our remoting =
strategies: RmiClientInterceptor has a "cacheRmiProxy" flag now, =
allowing to perform a fresh lookup if turned off. Analogously, =
JndiRmiClientInterceptor should be able to refetch its JNDI object now =
if the flag is turned off.
>
>Our EJB accessors have a similar "cacheHome" flag, which was =
implemented a bit crudely: If turned off, it simply overwrote the =
instance variable for the home object on every invocation - in a =
non-thread-safe manner. Preferably, it should simply fetch a new =
temporary proxy on each invocation in that case, just like =
RmiClientInterceptor does.
>
>Unfortunately, this means that our AbstractJndiLocator base class =
should change: It should not perform a lookup on initialization in any =
case and call located, but rather allow subclasses to explicitly call =
lookup when needed (i.e. either on initialization or on each invocation, =
depending on the respective flag).
>
>I've already adapted everything accordingly: All our remote accessors =
(which are based on proxies that need lookup, i.e. not the HTTP-based =
ones) have consistent support for configurable caching of proxies now.
>
>The question is: Can we live with the incompatible change in =
AbstractJndiLocator class (which is somewhat internal anyway)? Else, I =
could introduce a different base class for the above use case. However, =
that one would be very similar to the old AbstractJndiLocator, and we =
don't really have a need for the old locator class anymore...
>
>-----
>
>On a related note: Does a create call on a remote SLSB home usually =
involve actual remote communication, or is it rather implemented as =
local operation that returns a proxy for an actual SLSB instance? I was =
wondering whether our SimpleSlsbInvokerInterceptor actually causes =
communication overhead through its create call for each method =
invocation...
>
>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

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

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

I've actually changed AbstractJndiLocator's internal workings: =
Subclasses are supposed to explicitly call a "lookup()" method now, =
receiving the freshly located object, rather than getting a =
"located(Object)" callback on startup. This is necessary to implement =
true hot fetching of the JNDI object (just in time for calling a method =
on it, and throwing it away again right afterwards), without temporarily =
storing it in an instance variable.
=20
In terms of backwards compatibility, it's probably better to keep the =
AbstractJndiLocator as-is (deprecating it though) and put the new code =
into a JndiObjectLocator base class. Our remoting proxies can then =
derive from that new base class, with explicit lookup calls whenever =
they need them.
=20
There's actually four strategies that we could support out-of-the-box:
1. look up the JNDI object on bean initialization, storing it for later =
usage
2. look up the JNDI object on bean initialization (to determine =
interfaces or for validation), refetching it for every operation
3. look up the JNDI object on first need (first call to =
JndiObjectLocator.lookup), storing it for later usage
4. look up the JNDI object for every operation (every call to =
JndiObjectLocator.lookup)
=20
Number 1 is current standard behavior. Number 3 requires synchronized =
access to the stored JNDI object, but seems to be the appropriate =
behavior for EJB lookups (avoiding lazy-init on the bean and all objects =
that depend on it). Number 4 allows hot-redeploy of EJBs, mainly during =
development; number 2 does the same, but performs early validation, =
assuming that the lookup already works on startup.
=20
Regarding usage of remote EJB homes: What alternative strategies are =
there for our SimpleRemoteSlsbInvokerInterceptor, i.e. what could you do =
more efficiently if you accept some assumptions about your server? I =
could imagine that on some servers, creating the SLSB instance once and =
keeping it for the lifetime of the client application would work: Often, =
the SLSB instance is just a proxy that creates new calls to the servers =
every time, not allocating any resources on the server...
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Di 24.08.2004 21:01
An: spr...@li...
Betreff: Re: [Springframework-developer] JNDI object caching and =
AbstractJndiLocator



I don't think it's a big deal if AbstractJndiLocator doesn't do an
immediate lookup on initialization. I actually complained about the fact
that it did this a while ago, and this is why most people are
recommended to make their EJB proxies lazy, since a lot of the time the
JNDI tree is not ready at the time the JNDI lookup is done, if the proxy
is not set as ready, depending on the EJB environment. I would be
surprised if too many people are using this class, as opposed to
JndiObjectFactoryBean... Is this the only thing you want to change in
AbstractJndiLocator?

As for the question about remote communication on the usage of the home,
I don't think there's any guarantees here. A clustering EJB
implementation could very well do some remote communication on create
calls, if that makes the job of the cluster management code easier. It
is typically the bean stub itself that handles cluster failover, so I
dont think the home object actually has any real need to do remote
communications, but I don't remember there being any contract forbidding
it. I'm working from memory, but I do seem to remember that EJB 2.0 does
recommend that you now stay in your own VM, when creating a new stub,
for efficiency reasons. I.e. load balancing is no longer supposed to be
handled by automatically (by default) handing off to EJBs on different
cluster members, with that being recommended only for failover.

Colin

j=FCrgen h=F6ller [werk3AT] wrote:

>I've just checked remote proxy caching throughout our remoting =
strategies: RmiClientInterceptor has a "cacheRmiProxy" flag now, =
allowing to perform a fresh lookup if turned off. Analogously, =
JndiRmiClientInterceptor should be able to refetch its JNDI object now =
if the flag is turned off.
>
>Our EJB accessors have a similar "cacheHome" flag, which was =
implemented a bit crudely: If turned off, it simply overwrote the =
instance variable for the home object on every invocation - in a =
non-thread-safe manner. Preferably, it should simply fetch a new =
temporary proxy on each invocation in that case, just like =
RmiClientInterceptor does.
>
>Unfortunately, this means that our AbstractJndiLocator base class =
should change: It should not perform a lookup on initialization in any =
case and call located, but rather allow subclasses to explicitly call =
lookup when needed (i.e. either on initialization or on each invocation, =
depending on the respective flag).
>
>I've already adapted everything accordingly: All our remote accessors =
(which are based on proxies that need lookup, i.e. not the HTTP-based =
ones) have consistent support for configurable caching of proxies now.
>
>The question is: Can we live with the incompatible change in =
AbstractJndiLocator class (which is somewhat internal anyway)? Else, I =
could introduce a different base class for the above use case. However, =
that one would be very similar to the old AbstractJndiLocator, and we =
don't really have a need for the old locator class anymore...
>
>-----
>
>On a related note: Does a create call on a remote SLSB home usually =
involve actual remote communication, or is it rather implemented as =
local operation that returns a proxy for an actual SLSB instance? I was =
wondering whether our SimpleSlsbInvokerInterceptor actually causes =
communication overhead through its create call for each method =
invocation...
>
>Juergen
>=20
>




-------------------------------------------------------
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] Re: Hibernate 3

[Pavel T. <pch...@gm...>]

To me as an outsider and a user of Spring, Jurgen's sounds like the
best strategy so far.

Don't break the existing code simply to add a "2" to the package name,
it really doesn't mean much.

P

On Wed, 25 Aug 2004 09:13:56 +0200, j=FCrgen h=F6ller [werk3AT]
<jue...@we...> wrote:
> We do certainly not intend to drop Hibernate2 any time soon: It's too ubi=
quitous, and will be for some time to come. BTW, we also support both iBATI=
S SQL Maps 1.3.1 and 2.0: There, we have two different APIs in different iB=
ATIS 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 r=
enaming the old package might seem appropriate in terms of consistently app=
lying 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 cl=
assic 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 s=
upport classes for alpha software, particularly if it's such a large bunch =
as for Hibernate3. We can certainly add such classes as "orm.hibernate3" pa=
ckage to the sandbox, but they should remain there until there's at least a=
 beta release out.
>=20
> Juergen

Re: [Springframework-developer] Re: Hibernate 3

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

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
> 2.XX release could drop Hibernate 2, IMHO.  But that is a far bit
> 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 =
new
> > projects with.
> >
> > Tom K.
> >
> >
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On =
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 =
course
> > HB3 has a lot of new, shiny, sexy features :).
> >
> > > It's actually good that we didn't do anything before this, as =
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 =
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 =
same
> > > package names, but 'hibernate3' instead of just 'hibernate'. =
Arguably,
> > > the class names might make sense to have the version too, since it
> > would
> > > reduce confusion a lot.
> >
> > I'm not convinced. I thing most developers will switch from 2 to 3
> > within a
> > year. After that HB2 will be virtually outdated (like HB1 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 not "polluting" =
spring
> > packages. What about using "old" *.hibernate.* packages and adding
> > classes
> > with version suffix? Just 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 =
sandbox,
> > > and probably in the main source tree after 1.1 final is out. The =
main
> > > issue is developer time, although I see the work as being pretty
> > > straightforward to do a direct translation. It's 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 =
versions
> > with entity name.
> >
> > Having support for new hibernate - spring managed - events would be =
cool
> > also.
> >
> > Artur
> >
> > -------------------------------------------------------
> > 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
> >
> > ---
> > 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 =
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



-------------------------------------------------------
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] Re: Hibernate 3

[Martin K. <Mar...@St...>]

> I think Spring 1.XX should always work with Hibernate 2.  A Spring
> 2.XX release could drop Hibernate 2, IMHO.  But that is a far bit
> 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 new
> > projects with.
> >
> > Tom K.
> >
> >
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On 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 course
> > HB3 has a lot of new, shiny, sexy features :).
> >
> > > It's actually good that we didn't do anything before this, as 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 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 same
> > > package names, but 'hibernate3' instead of just 'hibernate'. Arguably,
> > > the class names might make sense to have the version too, since it
> > would
> > > reduce confusion a lot.
> >
> > I'm not convinced. I thing most developers will switch from 2 to 3
> > within a
> > year. After that HB2 will be virtually outdated (like HB1 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 not "polluting" spring
> > packages. What about using "old" *.hibernate.* packages and adding
> > classes
> > with version suffix? Just 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 sandbox,
> > > and probably in the main source tree after 1.1 final is out. The main
> > > issue is developer time, although I see the work as being pretty
> > > straightforward to do a direct translation. It's 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 versions
> > with entity name.
> >
> > Having support for new hibernate - spring managed - events would be cool
> > also.
> >
> > Artur
> >
> > -------------------------------------------------------
> > 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
> >
> > ---
> > 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 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] patch: cannot populate PDF metadata with AbstractPdfView

[Darren D. <da...@da...>]

On Tuesday 24 August 2004 23:38, Moses Hohman wrote:

> Right now there's no way to populate the meta information (e.g. title,
> creator, author, etc.) on a PDF document generated by
> org.springframework.web.servlet.view.document.AbstractPdfView. You
> can't populate it in getDocument(), because the PdfWriter hasn't been
> associated with the Document yet. And you can't populate it in
> buildPdfDocument(), because document.open() has already been called.

would you mind adding this to JIRA?  It seems pretty straightforward but 
stuff in JIRA won't go missing which can happen to list email and forum 
submissions.

Cheers,

-- 
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm

[Springframework-developer] patch: cannot populate PDF metadata with AbstractPdfView

[Moses H. <mmh...@no...>]

Hi,

Right now there's no way to populate the meta information (e.g. title, 
creator, author, etc.) on a PDF document generated by 
org.springframework.web.servlet.view.document.AbstractPdfView. You 
can't populate it in getDocument(), because the PdfWriter hasn't been 
associated with the Document yet. And you can't populate it in 
buildPdfDocument(), because document.open() has already been called.

Granted, not many are so anal as to actually want to do this, but for 
those that are, I submit the attached patch. I couldn't think of any 
way I could write a sensible unit test for this issue, so I didn't 
write one.

thanks,

Moses

[Springframework-developer] spring build.85 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.85</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build:&nbsp;</span>08/25/2004 00:16:31</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>13 minutes 48 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed:&nbsp;</span>08/24/2004 18:36:48</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try:&nbsp;</span>strip out images needed only for build, in pdf subdirector=
y</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;               =
     (21)                </td></tr><tr class=3D"modifications-evenrow"><td =
class=3D"modifications-data">modified</td><td class=3D"modifications-data">=
colins</td><td class=3D"modifications-data">/build.xml</td><td class=3D"mod=
ifications-data">strip out images needed only for build, in pdf subdirector=
y</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-da=
ta">deleted</td><td class=3D"modifications-data">colins</td><td class=3D"mo=
difications-data">docs/spring-reference.pdf</td><td class=3D"modifications-=
data">Include html_single docs in release builds. Remove spring-reference.p=
df from CVS, since it should be just generated by build</td></tr><tr class=
=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td><t=
d class=3D"modifications-data">colins</td><td class=3D"modifications-data">=
/build.xml</td><td class=3D"modifications-data">Include html_single docs in=
 release builds. Remove spring-reference.pdf from CVS, since it should be j=
ust generated by build</td></tr><tr class=3D"modifications-oddrow"><td clas=
s=3D"modifications-data">modified</td><td class=3D"modifications-data">aare=
ndsen</td><td class=3D"modifications-data">docs/reference/src/remoting.xml<=
/td><td class=3D"modifications-data">* Added piece on http invoker infrastr=
ucture</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modificati=
ons-data">modified</td><td class=3D"modifications-data">jhoeller</td><td cl=
ass=3D"modifications-data">test/org/springframework/web/servlet/handler/met=
adata/PathMapHandlerMappingTests.java</td><td class=3D"modifications-data">=
reworked "getClassesWithPathMapAttributes" to return a Class array rather t=
han names (removing the call to the deprecated Commons Attributes method th=
at returns class names)</td></tr><tr class=3D"modifications-oddrow"><td cla=
ss=3D"modifications-data">modified</td><td class=3D"modifications-data">jho=
eller</td><td class=3D"modifications-data">src/org/springframework/web/serv=
let/handler/metadata/AbstractPathMapHandlerMapping.java</td><td class=3D"mo=
difications-data">reworked "getClassesWithPathMapAttributes" to return a Cl=
ass array rather than names (removing the call to the deprecated Commons At=
tributes method that returns class names)</td></tr><tr class=3D"modificatio=
ns-evenrow"><td class=3D"modifications-data">modified</td><td class=3D"modi=
fications-data">jhoeller</td><td class=3D"modifications-data">src/org/sprin=
gframework/web/servlet/handler/metadata/CommonsPathMapHandlerMapping.java</=
td><td class=3D"modifications-data">reworked "getClassesWithPathMapAttribut=
es" to return a Class array rather than names (removing the call to the dep=
recated Commons Attributes method that returns class names)</td></tr><tr cl=
ass=3D"modifications-oddrow"><td class=3D"modifications-data">modified</td>=
<td class=3D"modifications-data">aarendsen</td><td class=3D"modifications-d=
ata">docs/reference/src/mvc.xml</td><td class=3D"modifications-data">* Expa=
nded the WizardFormController explanation a bit</td></tr><tr class=3D"modif=
ications-evenrow"><td class=3D"modifications-data">modified</td><td class=
=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">src/o=
rg/springframework/mail/javamail/MimeMessageHelper.java</td><td class=3D"mo=
difications-data">added "validateAddresses" property</td></tr><tr class=3D"=
modifications-oddrow"><td class=3D"modifications-data">modified</td><td cla=
ss=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">tes=
t/org/springframework/aop/target/ThreadLocalTargetSourceTests.java</td><td =
class=3D"modifications-data">deprecated "getObjects"/"getHits" etc in favou=
r of "getNrOfObjects"/"getNrOfHits"</td></tr><tr class=3D"modifications-eve=
nrow"><td class=3D"modifications-data">modified</td><td class=3D"modificati=
ons-data">jhoeller</td><td class=3D"modifications-data">src/org/springframe=
work/aop/target/ThreadLocalTargetSource.java</td><td class=3D"modifications=
-data">deprecated "getObjects"/"getHits" etc in favour of "getNrOfObjects"/=
"getNrOfHits"</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modi=
fications-data">modified</td><td class=3D"modifications-data">jhoeller</td>=
<td class=3D"modifications-data">src/org/springframework/aop/target/ThreadL=
ocalTargetSourceStats.java</td><td class=3D"modifications-data">deprecated =
"getObjects"/"getHits" etc in favour of "getNrOfObjects"/"getNrOfHits"</td>=
</tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-data">m=
odified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modi=
fications-data">lib/readme.txt</td><td class=3D"modifications-data">updated=
 to Java Activation Framework 1.0.2 and JavaMail 1.3.1</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"=
>lib/j2ee/activation.jar</td><td class=3D"modifications-data">updated to Ja=
va Activation Framework 1.0.2 and JavaMail 1.3.1</td></tr><tr class=3D"modi=
fications-evenrow"><td class=3D"modifications-data">modified</td><td class=
=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">lib/j=
2ee/mail.jar</td><td class=3D"modifications-data">updated to Java Activatio=
n Framework 1.0.2 and JavaMail 1.3.1</td></tr><tr class=3D"modifications-od=
drow"><td class=3D"modifications-data">modified</td><td class=3D"modificati=
ons-data">davison</td><td class=3D"modifications-data">src/org/springframew=
ork/web/servlet/view/velocity/spring.vm</td><td class=3D"modifications-data=
">fixed the springHtmlEscape check (again?) in springBind</td></tr><tr clas=
s=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td><=
td class=3D"modifications-data">kdonald</td><td class=3D"modifications-data=
">sandbox/src/org/springframework/rules/values/AbstractFormModel.java</td><=
td class=3D"modifications-data">allow CompoundForm to be nested</td></tr><t=
r class=3D"modifications-oddrow"><td class=3D"modifications-data">modified<=
/td><td class=3D"modifications-data">kdonald</td><td class=3D"modifications=
-data">sandbox/src/org/springframework/rules/values/CompoundFormModel.java<=
/td><td class=3D"modifications-data">allow CompoundForm to be nested</td></=
tr><tr class=3D"modifications-evenrow"><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/DefaultFormModel.=
java</td><td class=3D"modifications-data">allow CompoundForm to be nested</=
td></tr><tr class=3D"modifications-oddrow"><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/NestingFormMo=
del.java</td><td class=3D"modifications-data">allow CompoundForm to be nest=
ed</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-=
data">modified</td><td class=3D"modifications-data">kdonald</td><td class=
=3D"modifications-data">sandbox/src/org/springframework/rules/values/Valida=
tingFormModel.java</td><td class=3D"modifications-data">allow CompoundForm =
to be nested</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

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

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

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 new
> projects with.
> 
> Tom K.
> 
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On 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 course
> HB3 has a lot of new, shiny, sexy features :).
> 
> > It's actually good that we didn't do anything before this, as 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 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 same
> > package names, but 'hibernate3' instead of just 'hibernate'. Arguably,
> > the class names might make sense to have the version too, since it
> would
> > reduce confusion a lot.
> 
> I'm not convinced. I thing most developers will switch from 2 to 3
> within a
> year. After that HB2 will be virtually outdated (like HB1 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 not "polluting" spring
> packages. What about using "old" *.hibernate.* packages and adding
> classes
> with version suffix? Just 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 sandbox,
> > and probably in the main source tree after 1.1 final is out. The main
> > issue is developer time, although I see the work as being pretty
> > straightforward to do a direct translation. It's 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 versions
> with entity name.
> 
> Having support for new hibernate - spring managed - events would be cool
> also.
> 
> Artur
> 
> -------------------------------------------------------
> 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
> 
> ---
> 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 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 don't think it's a big deal if AbstractJndiLocator doesn't do an 
immediate lookup on initialization. I actually complained about the fact 
that it did this a while ago, and this is why most people are 
recommended to make their EJB proxies lazy, since a lot of the time the 
JNDI tree is not ready at the time the JNDI lookup is done, if the proxy 
is not set as ready, depending on the EJB environment. I would be 
surprised if too many people are using this class, as opposed to 
JndiObjectFactoryBean... Is this the only thing you want to change in 
AbstractJndiLocator?

As for the question about remote communication on the usage of the home, 
I don't think there's any guarantees here. A clustering EJB 
implementation could very well do some remote communication on create 
calls, if that makes the job of the cluster management code easier. It 
is typically the bean stub itself that handles cluster failover, so I 
dont think the home object actually has any real need to do remote 
communications, but I don't remember there being any contract forbidding 
it. I'm working from memory, but I do seem to remember that EJB 2.0 does 
recommend that you now stay in your own VM, when creating a new stub, 
for efficiency reasons. I.e. load balancing is no longer supposed to be 
handled by automatically (by default) handing off to EJBs on different 
cluster members, with that being recommended only for failover.

Colin

jürgen höller [werk3AT] wrote:

>I've just checked remote proxy caching throughout our remoting strategies: RmiClientInterceptor has a "cacheRmiProxy" flag now, allowing to perform a fresh lookup if turned off. Analogously, JndiRmiClientInterceptor should be able to refetch its JNDI object now if the flag is turned off.
>
>Our EJB accessors have a similar "cacheHome" flag, which was implemented a bit crudely: If turned off, it simply overwrote the instance variable for the home object on every invocation - in a non-thread-safe manner. Preferably, it should simply fetch a new temporary proxy on each invocation in that case, just like RmiClientInterceptor does.
>
>Unfortunately, this means that our AbstractJndiLocator base class should change: It should not perform a lookup on initialization in any case and call located, but rather allow subclasses to explicitly call lookup when needed (i.e. either on initialization or on each invocation, depending on the respective flag).
>
>I've already adapted everything accordingly: All our remote accessors (which are based on proxies that need lookup, i.e. not the HTTP-based ones) have consistent support for configurable caching of proxies now.
>
>The question is: Can we live with the incompatible change in AbstractJndiLocator class (which is somewhat internal anyway)? Else, I could introduce a different base class for the above use case. However, that one would be very similar to the old AbstractJndiLocator, and we don't really have a need for the old locator class anymore...
>
>-----
>
>On a related note: Does a create call on a remote SLSB home usually involve actual remote communication, or is it rather implemented as local operation that returns a proxy for an actual SLSB instance? I was wondering whether our SimpleSlsbInvokerInterceptor actually causes communication overhead through its create call for each method invocation...
>
>Juergen
>  
>

RE: [Springframework-developer] Re: Hibernate 3

[Tom K <tk...@co...>]

I second this (anyone else?). Hibernate3 will be what I develop my new
projects with.

Tom K.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On 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 course
HB3 has a lot of new, shiny, sexy features :).
 
> It's actually good that we didn't do anything before this, as 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 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 same
> package names, but 'hibernate3' instead of just 'hibernate'. Arguably,
> the class names might make sense to have the version too, since it
would
> reduce confusion a lot.

I'm not convinced. I thing most developers will switch from 2 to 3
within a
year. After that HB2 will be virtually outdated (like HB1 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 not "polluting" spring
packages. What about using "old" *.hibernate.* packages and adding
classes
with version suffix? Just 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 sandbox,
> and probably in the main source tree after 1.1 final is out. The main
> issue is developer time, although I see the work as being pretty
> straightforward to do a direct translation. It's 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 versions
with entity name.

Having support for new hibernate - spring managed - events would be cool
also.

Artur



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

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

[Springframework-developer] Re: Hibernate 3

[Artur K. <kar...@as...>]

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 course
HB3 has a lot of new, shiny, sexy features :).
 
> It's actually good that we didn't do anything before this, as 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 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 same
> package names, but 'hibernate3' instead of just 'hibernate'. Arguably,
> the class names might make sense to have the version too, since it would
> reduce confusion a lot.

I'm not convinced. I thing most developers will switch from 2 to 3 within a
year. After that HB2 will be virtually outdated (like HB1 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 not "polluting" spring
packages. What about using "old" *.hibernate.* packages and adding classes
with version suffix? Just 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 sandbox,
> and probably in the main source tree after 1.1 final is out. The main
> issue is developer time, although I see the work as being pretty
> straightforward to do a direct translation. It's 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 versions
with entity name.

Having support for new hibernate - spring managed - events would be cool
also.

Artur

[Springframework-developer] JNDI object caching and AbstractJndiLocator

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

I've just checked remote proxy caching throughout our remoting =
strategies: RmiClientInterceptor has a "cacheRmiProxy" flag now, =
allowing to perform a fresh lookup if turned off. Analogously, =
JndiRmiClientInterceptor should be able to refetch its JNDI object now =
if the flag is turned off.

Our EJB accessors have a similar "cacheHome" flag, which was implemented =
a bit crudely: If turned off, it simply overwrote the instance variable =
for the home object on every invocation - in a non-thread-safe manner. =
Preferably, it should simply fetch a new temporary proxy on each =
invocation in that case, just like RmiClientInterceptor does.

Unfortunately, this means that our AbstractJndiLocator base class should =
change: It should not perform a lookup on initialization in any case and =
call located, but rather allow subclasses to explicitly call lookup when =
needed (i.e. either on initialization or on each invocation, depending =
on the respective flag).

I've already adapted everything accordingly: All our remote accessors =
(which are based on proxies that need lookup, i.e. not the HTTP-based =
ones) have consistent support for configurable caching of proxies now.

The question is: Can we live with the incompatible change in =
AbstractJndiLocator class (which is somewhat internal anyway)? Else, I =
could introduce a different base class for the above use case. However, =
that one would be very similar to the old AbstractJndiLocator, and we =
don't really have a need for the old locator class anymore...

-----

On a related note: Does a create call on a remote SLSB home usually =
involve actual remote communication, or is it rather implemented as =
local operation that returns a proxy for an actual SLSB instance? I was =
wondering whether our SimpleSlsbInvokerInterceptor actually causes =
communication overhead through its create call for each method =
invocation...

Juergen

[Springframework-developer] Build release now includes html_single version of html docs

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

I've modified the build script to include the html_single version of the 
html docs in the two release packages. If somebody thinks that the 
normal (split out) html version is a better idea to be included, or we 
should include both, just speak up.

Note that I've modified the "release" target to also depend on "refdoc". 
The old version didn't, which meant it was very easy to build a release 
with old docs. Additionally, I've made the build fail with a nice 
message if the XSLT support libs are not available where they should be 
(since this is a manual step that people have to do). I have also killed 
the version of spring-reference.pdf which was checked in under /docs. It 
did not make sense to me to have that version there, which had to be 
manually updated, when we generate a fresh one automatically under 
/docs/reference/pdf. The build now just includes the one under 
/docs/reference/pdf.

Regards,
Colin  

Colin Sampaleanu wrote:

> I'll do it. It's just a bit of playing with the build script.
>
> jürgen höller [werk3AT] wrote:
>
>> Any thoughts on such an HTML version of the reference docs? Not for 
>> 1.1 RC2, which I'll release tomorrow morning, but for 1.1 final...
>>
>> Juergen
>>
>>
>> ________________________________
>>
>> Von: spr...@li... im Auftrag 
>> von jürgen höller [werk3AT]
>> Gesendet: Di 17.08.2004 23:52
>> An: spr...@li...
>> Betreff: Re: [Springframework-developer] Preparing for Spring 1.1 final
>>
>>
>>
>> Colin,
>>
>> Can you have a look at this? We could indeed ship an HTML version of 
>> the reference docs too... What do you think?
>>
>> Juergen
>>
>>
>> ________________________________
>>
>> Von: spr...@li... im Auftrag 
>> von Aleksei Gopachenko
>> Gesendet: Di 17.08.2004 13:18
>> An: spr...@li...
>> Betreff: Re: [Springframework-developer] Preparing for Spring 1.1 final
>>
>>
>>
>> On Sat, 14 Aug 2004 21:03:40 +0200, jürgen höller [werk3AT]
>> <jue...@we...> wrote:
>>
>>  
>>
>>> From my point of view, Spring 1.1 final is ready for release; the only
>>> remaining point is documentation.
>>>   
>>
>>
>> Guys, is there any chance that html versions of docs will be included in
>> binary distribution?
>> PDF is great, but IMO at least html_single version should go in.
>>
>> -- 
>>
>> //regards, neuro
>

[Springframework-developer] Hibernate 3

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

Hibernate 3 is now out in Alpha. We should probably start thinking about 
how to add support for it, and a timeframe.

It's actually good that we didn't do anything before this, as 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 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 same 
package names, but 'hibernate3' instead of just 'hibernate'. Arguably, 
the class names might make sense to have the version too, since it would 
reduce confusion a lot.

In terms of a timeframe, this could happen at any time in the sandbox, 
and probably in the main source tree after 1.1 final is out. The main 
issue is developer time, although I see the work as being pretty 
straightforward to do a direct translation. It's 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...

Colin

[Springframework-developer] spring build.84 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.84</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build:&nbsp;</span>08/24/2004 00:14:57</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>13 minutes 30 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed:&nbsp;</span>08/23/2004 15:56:12</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try:&nbsp;</span>Added test for CGLIB class that implements no interfaces</=
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;               =
     (68)                </td></tr><tr class=3D"modifications-evenrow"><td =
class=3D"modifications-data">modified</td><td class=3D"modifications-data">=
johnsonr</td><td class=3D"modifications-data">test/org/springframework/tran=
saction/interceptor/BeanFactoryTransactionTests.java</td><td class=3D"modif=
ications-data">Added test for CGLIB class that implements no interfaces</td=
></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">a=
dded</td><td class=3D"modifications-data">johnsonr</td><td class=3D"modific=
ations-data">test/org/springframework/transaction/interceptor/ImplementsNoI=
nterfaces.java</td><td class=3D"modifications-data">Added test for CGLIB cl=
ass that implements no interfaces</td></tr><tr class=3D"modifications-evenr=
ow"><td class=3D"modifications-data">modified</td><td class=3D"modification=
s-data">johnsonr</td><td class=3D"modifications-data">test/org/springframew=
ork/transaction/interceptor/transactionalBeanFactory.xml</td><td class=3D"m=
odifications-data">Added test for CGLIB class that implements no interfaces=
</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-dat=
a">modified</td><td class=3D"modifications-data">johnsonr</td><td class=3D"=
modifications-data">test/org/springframework/transaction/interceptor/BeanFa=
ctoryTransactionTests.java</td><td class=3D"modifications-data">Added furth=
er CGLIB test</td></tr><tr class=3D"modifications-evenrow"><td class=3D"mod=
ifications-data">modified</td><td class=3D"modifications-data">johnsonr</td=
><td class=3D"modifications-data">test/org/springframework/transaction/inte=
rceptor/transactionalBeanFactory.xml</td><td class=3D"modifications-data">A=
dded further CGLIB test</td></tr><tr class=3D"modifications-oddrow"><td cla=
ss=3D"modifications-data">added</td><td class=3D"modifications-data">kdonal=
d</td><td class=3D"modifications-data">sandbox/src/org/springframework/rule=
s/values/AbstractFormModel.java</td><td class=3D"modifications-data">ollie'=
s form model refactoring; introduction of abstract form model</td></tr><tr =
class=3D"modifications-evenrow"><td class=3D"modifications-data">modified</=
td><td class=3D"modifications-data">kdonald</td><td class=3D"modifications-=
data">sandbox/src/org/springframework/rules/values/CompoundFormModel.java</=
td><td class=3D"modifications-data">ollie's form model refactoring; introdu=
ction of abstract form model</td></tr><tr class=3D"modifications-oddrow"><t=
d class=3D"modifications-data">modified</td><td class=3D"modifications-data=
">kdonald</td><td class=3D"modifications-data">sandbox/src/org/springframew=
ork/rules/values/DefaultFormModel.java</td><td class=3D"modifications-data"=
>ollie's form model refactoring; introduction of abstract form model</td></=
tr><tr class=3D"modifications-evenrow"><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/AbstractValueMode=
l.java</td><td class=3D"modifications-data">npe in fireValueChanged</td></t=
r><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">modif=
ied</td><td class=3D"modifications-data">colins</td><td class=3D"modificati=
ons-data">autobuilds/apps/ejbtest/src/webapp/WEB-INF/classes/servicelayer-a=
pplicationContext.xml</td><td class=3D"modifications-data">add better comme=
nt</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-=
data">modified</td><td class=3D"modifications-data">davison</td><td class=
=3D"modifications-data">docs/reference/src/views.xml</td><td class=3D"modif=
ications-data">update macros for Map parameters</td></tr><tr class=3D"modif=
ications-oddrow"><td class=3D"modifications-data">modified</td><td class=3D=
"modifications-data">davison</td><td class=3D"modifications-data">src/org/s=
pringframework/web/servlet/view/freemarker/spring.ftl</td><td class=3D"modi=
fications-data">update macros for Map parameters</td></tr><tr class=3D"modi=
fications-evenrow"><td class=3D"modifications-data">modified</td><td class=
=3D"modifications-data">davison</td><td class=3D"modifications-data">src/or=
g/springframework/web/servlet/view/velocity/spring.vm</td><td class=3D"modi=
fications-data">update macros for Map parameters</td></tr><tr class=3D"modi=
fications-oddrow"><td class=3D"modifications-data">modified</td><td class=
=3D"modifications-data">davison</td><td class=3D"modifications-data">src/or=
g/springframework/web/servlet/view/xslt/AbstractXsltView.java</td><td class=
=3D"modifications-data">fix to make relative imports work without requiring=
 a custom URI resolver.  SPR-261</td></tr><tr class=3D"modifications-evenro=
w"><td class=3D"modifications-data">modified</td><td class=3D"modifications=
-data">colins</td><td class=3D"modifications-data">autobuilds/apps/ejbtest/=
src/webapp/WEB-INF/classes/servicelayer-applicationContext.xml</td><td clas=
s=3D"modifications-data">Add examples of EJBs with CMT+SpringTx, CMT with n=
o Spring Tx, and No CMT + Spring Tx</td></tr><tr class=3D"modifications-odd=
row"><td class=3D"modifications-data">deleted</td><td class=3D"modification=
s-data">colins</td><td class=3D"modifications-data">autobuilds/apps/ejbtest=
/README</td><td class=3D"modifications-data">Add examples of EJBs with CMT+=
SpringTx, CMT with no Spring Tx, and No CMT + Spring Tx</td></tr><tr class=
=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td><t=
d class=3D"modifications-data">colins</td><td class=3D"modifications-data">=
autobuilds/apps/ejbtest/build.xml</td><td class=3D"modifications-data">Add =
examples of EJBs with CMT+SpringTx, CMT with no Spring Tx, and No CMT + Spr=
ing Tx</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modificatio=
ns-data">added</td><td class=3D"modifications-data">colins</td><td class=3D=
"modifications-data">autobuilds/apps/ejbtest/readme.txt</td><td class=3D"mo=
difications-data">Add examples of EJBs with CMT+SpringTx, CMT with no Sprin=
g Tx, and No CMT + Spring Tx</td></tr><tr class=3D"modifications-evenrow"><=
td class=3D"modifications-data">modified</td><td class=3D"modifications-dat=
a">colins</td><td class=3D"modifications-data">autobuilds/apps/ejbtest/src/=
ejb/ejb-jar.xml</td><td class=3D"modifications-data">Add examples of EJBs w=
ith CMT+SpringTx, CMT with no Spring Tx, and No CMT + Spring Tx</td></tr><t=
r class=3D"modifications-oddrow"><td class=3D"modifications-data">deleted</=
td><td class=3D"modifications-data">colins</td><td class=3D"modifications-d=
ata">autobuilds/apps/ejbtest/src/test-cactus/org/apache/cactus/sample/ejb/C=
onverterEJBTest.java</td><td class=3D"modifications-data">Add examples of E=
JBs with CMT+SpringTx, CMT with no Spring Tx, and No CMT + Spring Tx</td></=
tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-data">add=
ed</td><td class=3D"modifications-data">colins</td><td class=3D"modificatio=
ns-data">autobuilds/apps/ejbtest/src/test-cactus/org/apache/cactus/sample/e=
jb/ConverterEJBTests.java</td><td class=3D"modifications-data">Add examples=
 of EJBs with CMT+SpringTx, CMT with no Spring Tx, and No CMT + Spring Tx</=
td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data"=
>modified</td><td class=3D"modifications-data">davison</td><td class=3D"mod=
ifications-data">src/org/springframework/web/servlet/view/freemarker/FreeMa=
rkerView.java</td><td class=3D"modifications-data">don't hide parse errors =
when loading template.  SPR-279</td></tr><tr class=3D"modifications-evenrow=
"><td class=3D"modifications-data">modified</td><td class=3D"modifications-=
data">colins</td><td class=3D"modifications-data">autobuilds/apps/ejbtest/s=
rc/webapp/WEB-INF/classes/servicelayer-applicationContext.xml</td><td class=
=3D"modifications-data">clean up ejb samples</td></tr><tr class=3D"modifica=
tions-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"mo=
difications-data">trisberg</td><td class=3D"modifications-data">src/org/spr=
ingframework/jdbc/core/JdbcTemplate.java</td><td class=3D"modifications-dat=
a">added debug messages based supportsBatchUpdate value and also code to ca=
tch AbstractMethodError for the same</td></tr><tr class=3D"modifications-ev=
enrow"><td class=3D"modifications-data">modified</td><td class=3D"modificat=
ions-data">colins</td><td class=3D"modifications-data">docs/reference/src/m=
vc.xml</td><td class=3D"modifications-data">fix CommonsMultipartResolver pa=
ram errors</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modific=
ations-data">modified</td><td class=3D"modifications-data">colins</td><td c=
lass=3D"modifications-data">src/org/springframework/web/multipart/commons/C=
ommonsMultipartResolver.java</td><td class=3D"modifications-data">fix 3-4 J=
avaDoc param name errors</td></tr><tr class=3D"modifications-evenrow"><td c=
lass=3D"modifications-data">modified</td><td class=3D"modifications-data">j=
hoeller</td><td class=3D"modifications-data">/changelog.txt</td><td class=
=3D"modifications-data">reworked DynamicDestinationResolver and JndiDestina=
tionResolver</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modif=
ications-data">modified</td><td class=3D"modifications-data">jhoeller</td><=
td class=3D"modifications-data">test/org/springframework/orm/hibernate/supp=
ort/OpenSessionInViewTests.java</td><td class=3D"modifications-data">return=
 default thread-bound Session even if JTA TransactionManager is available b=
ut no transaction is active</td></tr><tr class=3D"modifications-evenrow"><t=
d class=3D"modifications-data">modified</td><td class=3D"modifications-data=
">jhoeller</td><td class=3D"modifications-data">src/org/springframework/orm=
/hibernate/SessionFactoryUtils.java</td><td class=3D"modifications-data">re=
turn default thread-bound Session even if JTA TransactionManager is availab=
le but no transaction is active</td></tr><tr class=3D"modifications-oddrow"=
><td class=3D"modifications-data">modified</td><td class=3D"modifications-d=
ata">jhoeller</td><td class=3D"modifications-data">/project.properties</td>=
<td class=3D"modifications-data">updated for 1.1 final</td></tr><tr class=
=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td><t=
d class=3D"modifications-data">jhoeller</td><td class=3D"modifications-data=
">/readme.txt</td><td class=3D"modifications-data">updated for 1.1 final</t=
d></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">=
modified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"mod=
ifications-data">docs/reference/src/index.xml</td><td class=3D"modification=
s-data">updated for 1.1 final</td></tr><tr class=3D"modifications-evenrow">=
<td class=3D"modifications-data">modified</td><td class=3D"modifications-da=
ta">jhoeller</td><td class=3D"modifications-data">/changelog.txt</td><td cl=
ass=3D"modifications-data">added JNDI RMI support</td></tr><tr class=3D"mod=
ifications-oddrow"><td class=3D"modifications-data">modified</td><td class=
=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">src/o=
rg/springframework/remoting/support/RemoteAccessor.java</td><td class=3D"mo=
difications-data">added null check in setServiceInterface</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/remoting/support/RemoteExporter.java</td><td cla=
ss=3D"modifications-data">added null check in setServiceInterface</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/remoting/rmi/JndiRmiClientInterceptor.java</=
td><td class=3D"modifications-data">added JndiRmiServiceExporter and JndiRm=
iClientInterceptor/JndiRmiProxyFactoryBean</td></tr><tr class=3D"modificati=
ons-evenrow"><td class=3D"modifications-data">added</td><td class=3D"modifi=
cations-data">jhoeller</td><td class=3D"modifications-data">src/org/springf=
ramework/remoting/rmi/JndiRmiProxyFactoryBean.java</td><td class=3D"modific=
ations-data">added JndiRmiServiceExporter and JndiRmiClientInterceptor/Jndi=
RmiProxyFactoryBean</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/remoting/rmi/=
JndiRmiServiceExporter.java</td><td class=3D"modifications-data">added Jndi=
RmiServiceExporter and JndiRmiClientInterceptor/JndiRmiProxyFactoryBean</td=
></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-data">=
modified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"mod=
ifications-data">src/org/springframework/remoting/jaxrpc/JaxRpcPortClientIn=
terceptor.java</td><td class=3D"modifications-data">factored out RMI invoca=
tion logic into RmiClientInterceptorUtils, handling both RMI and non-RMI se=
rvice interfaces</td></tr><tr class=3D"modifications-oddrow"><td class=3D"m=
odifications-data">modified</td><td class=3D"modifications-data">jhoeller</=
td><td class=3D"modifications-data">src/org/springframework/remoting/rmi/Rm=
iClientInterceptor.java</td><td class=3D"modifications-data">factored out R=
MI invocation logic into RmiClientInterceptorUtils, handling both RMI and n=
on-RMI service interfaces</td></tr><tr class=3D"modifications-evenrow"><td =
class=3D"modifications-data">added</td><td class=3D"modifications-data">jho=
eller</td><td class=3D"modifications-data">src/org/springframework/remoting=
/rmi/RmiClientInterceptorUtils.java</td><td class=3D"modifications-data">fa=
ctored out RMI invocation logic into RmiClientInterceptorUtils, handling bo=
th RMI and non-RMI service interfaces</td></tr><tr class=3D"modifications-o=
ddrow"><td class=3D"modifications-data">modified</td><td class=3D"modificat=
ions-data">jhoeller</td><td class=3D"modifications-data">src/org/springfram=
ework/remoting/rmi/RmiProxyFactoryBean.java</td><td class=3D"modifications-=
data">factored out RMI invocation logic into RmiClientInterceptorUtils, han=
dling both RMI and non-RMI service interfaces</td></tr><tr class=3D"modific=
ations-evenrow"><td class=3D"modifications-data">modified</td><td class=3D"=
modifications-data">jhoeller</td><td class=3D"modifications-data">src/org/s=
pringframework/remoting/rmi/RmiServiceExporter.java</td><td class=3D"modifi=
cations-data">factored out "getRegistry" and "getObjectToExport" from "afte=
rPropertiesSet"</td></tr><tr class=3D"modifications-oddrow"><td class=3D"mo=
difications-data">modified</td><td class=3D"modifications-data">jhoeller</t=
d><td class=3D"modifications-data">src/org/springframework/remoting/support=
/RemoteExporter.java</td><td class=3D"modifications-data">refactoed RemoteE=
xporter's "afterPropertiesSet" into "checkService" and "checkServiceInterfa=
ce"</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications=
-data">modified</td><td class=3D"modifications-data">jhoeller</td><td class=
=3D"modifications-data">src/org/springframework/remoting/caucho/BurlapServi=
ceExporter.java</td><td class=3D"modifications-data">refactoed RemoteExport=
er's "afterPropertiesSet" into "checkService" and "checkServiceInterface"</=
td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data"=
>modified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"mo=
difications-data">src/org/springframework/remoting/caucho/HessianServiceExp=
orter.java</td><td class=3D"modifications-data">refactoed RemoteExporter's =
"afterPropertiesSet" into "checkService" and "checkServiceInterface"</td></=
tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-data">mod=
ified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modifi=
cations-data">test/org/springframework/jndi/JndiTemplateTests.java</td><td =
class=3D"modifications-data">added "rebind" operation</td></tr><tr class=3D=
"modifications-oddrow"><td class=3D"modifications-data">modified</td><td cl=
ass=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">sr=
c/org/springframework/jndi/AbstractJndiLocator.java</td><td class=3D"modifi=
cations-data">polishing</td></tr><tr class=3D"modifications-evenrow"><td cl=
ass=3D"modifications-data">modified</td><td class=3D"modifications-data">jh=
oeller</td><td class=3D"modifications-data">src/org/springframework/orm/hib=
ernate/SessionFactoryUtils.java</td><td class=3D"modifications-data">polish=
ing</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/AbstractSlsbInvo=
kerInterceptor.java</td><td class=3D"modifications-data">polishing</td></tr=
><tr class=3D"modifications-evenrow"><td class=3D"modifications-data">modif=
ied</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modifica=
tions-data">src/org/springframework/jndi/JndiTemplate.java</td><td class=3D=
"modifications-data">added "rebind" operation</td></tr><tr class=3D"modific=
ations-oddrow"><td class=3D"modifications-data">added</td><td class=3D"modi=
fications-data">jhoeller</td><td class=3D"modifications-data">src/org/sprin=
gframework/jndi/JndiAccessor.java</td><td class=3D"modifications-data">fact=
ored out JndiAccessor base class from JndiLocatorSupport</td></tr><tr class=
=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td><t=
d class=3D"modifications-data">jhoeller</td><td class=3D"modifications-data=
">src/org/springframework/jndi/JndiLocatorSupport.java</td><td class=3D"mod=
ifications-data">factored out JndiAccessor base class from JndiLocatorSuppo=
rt</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-d=
ata">modified</td><td class=3D"modifications-data">jhoeller</td><td class=
=3D"modifications-data">test/org/springframework/aop/framework/autoproxy/Au=
toProxyCreatorTestSuite.java</td><td class=3D"modifications-data">adapted e=
xpected number of invocations from 18 to 19 (not sure what change caused th=
is; possibly some BeanFactory internals)</td></tr><tr class=3D"modification=
s-evenrow"><td class=3D"modifications-data">modified</td><td class=3D"modif=
ications-data">jhoeller</td><td class=3D"modifications-data">test/org/sprin=
gframework/beans/BeanWrapperTestSuite.java</td><td class=3D"modifications-d=
ata">reworked property-specific custom editor handling to allow registratio=
n for uninitialized subpaths</td></tr><tr class=3D"modifications-oddrow"><t=
d class=3D"modifications-data">modified</td><td class=3D"modifications-data=
">jhoeller</td><td class=3D"modifications-data">test/org/springframework/be=
ans/IndexedTestBean.java</td><td class=3D"modifications-data">reworked prop=
erty-specific custom editor handling to allow registration for uninitialize=
d subpaths</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifi=
cations-data">modified</td><td class=3D"modifications-data">jhoeller</td><t=
d class=3D"modifications-data">src/org/springframework/beans/BeanWrapperImp=
l.java</td><td class=3D"modifications-data">reworked property-specific cust=
om editor handling to allow registration for uninitialized subpaths</td></t=
r><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">modif=
ied</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modifica=
tions-data">src/org/springframework/remoting/support/RemoteInvocationBasedE=
xporter.java</td><td class=3D"modifications-data">changed exception holder =
to Throwable, to also transport errors thrown during reflection</td></tr><t=
r class=3D"modifications-evenrow"><td class=3D"modifications-data">modified=
</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modificatio=
ns-data">src/org/springframework/remoting/support/RemoteInvocationResult.ja=
va</td><td class=3D"modifications-data">changed exception holder to Throwab=
le, to also transport errors thrown during reflection</td></tr><tr class=3D=
"modifications-oddrow"><td class=3D"modifications-data">modified</td><td cl=
ass=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">te=
st/org/springframework/orm/hibernate/HibernateJtaTransactionTests.java</td>=
<td class=3D"modifications-data">fixed JTA synchronization with a Hibernate=
 TransactionManagerLookup</td></tr><tr class=3D"modifications-evenrow"><td =
class=3D"modifications-data">modified</td><td class=3D"modifications-data">=
jhoeller</td><td class=3D"modifications-data">src/org/springframework/orm/h=
ibernate/SessionFactoryUtils.java</td><td class=3D"modifications-data">fixe=
d JTA synchronization with a Hibernate TransactionManagerLookup</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">test/org/springframework/web/servlet/mvc/CommandControllerTestSuite=
.java</td><td class=3D"modifications-data">apply PropertyEditor.getAsText t=
o null value too</td></tr><tr class=3D"modifications-evenrow"><td class=3D"=
modifications-data">modified</td><td class=3D"modifications-data">jhoeller<=
/td><td class=3D"modifications-data">src/org/springframework/validation/Bin=
dException.java</td><td class=3D"modifications-data">apply PropertyEditor.g=
etAsText to null value too</td></tr><tr class=3D"modifications-oddrow"><td =
class=3D"modifications-data">modified</td><td class=3D"modifications-data">=
kdonald</td><td class=3D"modifications-data">sandbox/src/org/springframewor=
k/rules/values/BufferedValueModel.java</td><td class=3D"modifications-data"=
>ok grab this fix and all should be ready to go again - keith</td></tr><tr =
class=3D"modifications-evenrow"><td class=3D"modifications-data">modified</=
td><td class=3D"modifications-data">trisberg</td><td class=3D"modifications=
-data">src/org/springframework/jdbc/core/JdbcTemplate.java</td><td class=3D=
"modifications-data">modified parameter placeholder check to allow for lite=
rals to be delimited by both single and double quotes</td></tr><tr class=3D=
"modifications-oddrow"><td class=3D"modifications-data">modified</td><td cl=
ass=3D"modifications-data">trisberg</td><td class=3D"modifications-data">te=
st/org/springframework/jdbc/support/JdbcUtilsTests.java</td><td class=3D"mo=
difications-data">modified parameter placeholder check to allow for literal=
s to be delimited by both single and double quotes</td></tr><tr class=3D"mo=
difications-evenrow"><td class=3D"modifications-data">modified</td><td clas=
s=3D"modifications-data">trisberg</td><td class=3D"modifications-data">src/=
org/springframework/jdbc/object/SqlOperation.java</td><td class=3D"modifica=
tions-data">modified parameter placeholder check to allow for literals to b=
e delimited by both single and double quotes</td></tr><tr class=3D"modifica=
tions-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"mo=
difications-data">trisberg</td><td class=3D"modifications-data">src/org/spr=
ingframework/jdbc/support/JdbcUtils.java</td><td class=3D"modifications-dat=
a">modified parameter placeholder check to allow for literals to be delimit=
ed by both single and double quotes</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] Website Announcement

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

Thanks

Tim Nolan wrote:

> Small thing - the announcement "We are pleasewd" should be "We are 
> pleased" (unless I've got Elmer Fudd preferences on) :)

[Springframework-developer] Website Announcement

[Tim N. <kat...@ho...>]

Small thing - the announcement "We are pleasewd" should be "We are 
pleased" (unless I've got Elmer Fudd preferences on) :)

[Springframework-developer] ejbtest integration test sample app upgraded

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

All,

I've done some more work on the 'ejbtest' ejb integration test app under 
autobuilds. There are now some pretty examples of EJBs which are 
configured for:
- CMT + Spring Tx, ultimately doing Hibernate operations
- CMT with _no_ Spring Tx, ultimately doing Hibernate operations
- _no_ CMT but with Spring Tx, ultimately doing Hibernate operations

Anybody on the forums confused about how to use Spring's EJB support in 
one of these scenarios should probably be directed to check out this 
code and look at it.

There are still the existing tests with test the cache flag on the 
proxy, and a lower level test which manually verifies that a Hibernate 
Session is bound to the JTA Transaction, and that same Session is 
available later in that Transaction, when using CMT without Spring TX 
(and with Hibernate's JTA TransactionManager lookup configured properly).

Regards,
Colin

Re: [Springframework-developer] declaritive context visibility of bean definitions?

[Martin K. <Mar...@St...>]

There is also an thread within the new forum. Maybe someone should
take a look. There were some issues raised about the visibility, =
extendability
of application contexts.
  ----- Original Message -----=20
  From: Rod Johnson=20
  To: spr...@li...=20
  Sent: Saturday, August 21, 2004 2:38 PM
  Subject: RE: [Springframework-developer] declaritive context =
visibility of bean definitions?


  Such visibility options make sense IMO. However, I would prefer that =
this was considered for 1.2 rather than 1.1 final.=20

  As with abstract definitions, enumeration methods on =
ListableBeanFactory shouldn't return non-public beans.

  Btw, inner beans are a good alternative: for example, instead of the =
xxxx/xxxTarget combination for ProxyFactoryBean, just xxxx, with the =
target an anonymous inner bean.



-------------------------------------------------------------------------=
-----
  From: spr...@li... =
[mailto:spr...@li...] On Behalf =
Of jbetancourt
  Sent: 21 August 2004 12:12
  To: spr...@li...
  Subject: [Springframework-developer] declaritive context visibility of =
bean definitions?


  Just had a thought while reading the 'explicity abstract' message.  =20

  Would it make sense to have the ability to make bean definitions =
'private', that is local only to other beans in the same context, and =
the default is 'public'?    I can't think of a use-case for this or if =
it is already possible in current Spring core.


  <bean   ......    access=3D"public" />

  or=20

  <bean  .......   public=3D"false" />



  Just a thought.

RE: [Springframework-developer] declaritive context visibility of bean definitions?

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

Such visibility options make sense IMO. However, I would prefer that this
was considered for 1.2 rather than 1.1 final. 
 
As with abstract definitions, enumeration methods on ListableBeanFactory
shouldn't return non-public beans.
 
Btw, inner beans are a good alternative: for example, instead of the
xxxx/xxxTarget combination for ProxyFactoryBean, just xxxx, with the target
an anonymous inner bean.

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
jbetancourt
Sent: 21 August 2004 12:12
To: spr...@li...
Subject: [Springframework-developer] declaritive context visibility of bean
definitions?


Just had a thought while reading the 'explicity abstract' message.   
 
Would it make sense to have the ability to make bean definitions 'private',
that is local only to other beans in the same context, and the default is
'public'?    I can't think of a use-case for this or if it is already
possible in current Spring core.
 
 
<bean   ......    access="public" />
 
or 
 
<bean  .......   public="false" />
 
 
 
Just a thought.
 
 
 
 
 
 

[Springframework-developer] declaritive context visibility of bean definitions?

[jbetancourt <jbe...@co...>]

Just had a thought while reading the 'explicity abstract' message.  =20

Would it make sense to have the ability to make bean definitions =
'private', that is local only to other beans in the same context, and =
the default is 'public'?    I can't think of a use-case for this or if =
it is already possible in current Spring core.


<bean   ......    access=3D"public" />

or=20

<bean  .......   public=3D"false" />



Just a thought.

Re: [Springframework-developer] HibernateInterceptor

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

I was just about to point exactly that out :-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Sa 21.08.2004 00:33
An: spr...@li...
Betreff: Re: [Springframework-developer] HibernateInterceptor



Actually, to correct myself, it looks like SessionFactoryUtils does take
care of things.

If the session has been pre-bound with no tx existing (via
OpenSessionInViewFilter classic mode, or HibernateInterceptor), then you
start a new transaction, then you do a SessionFactoryUtils.getSession
(which everything goes through), this piece of code will ensure that the
session is still registered for transaction synchronizaiton after the =
fact:

        SessionHolder sessionHolder =3D (SessionHolder)
TransactionSynchronizationManager.getResource(sessionFactory);
        if (sessionHolder !=3D null) {
            if
(TransactionSynchronizationManager.isSynchronizationActive()) {
                if (allowSynchronization &&
!sessionHolder.isSynchronizedWithTransaction()) {
                    logger.debug("Registering Spring transaction
synchronization for existing Hibernate session");
                  =20
TransactionSynchronizationManager.registerSynchronization(
                            new
SpringSessionSynchronization(sessionHolder, sessionFactory,
jdbcExceptionTranslator, false));
                    sessionHolder.setSynchronizedWithTransaction(true);
                }
                return sessionHolder.getSession();
            }

Now this is only going to happen when some code actually calls
getSession(), so the timing will not be exactly the same as if you used
TransactionInterceptor followed by HibernateInterceptor, but the results
in usage should be the same for all intents and purposes...

Regards,
Colin


Colin Sampaleanu wrote:

> If you use the new mode of the OpenSessionInViewFilter where there are
> multiple sessions, but close is deferred, then in fact there is no
> existing session yet.
>
> If you use the old mode, with just one session, then it's probably not
> the end of the world. The tx sync ensures a flush, and also a callback
> into Hibernate's SessionImplementor.afterTransactionCompletion()
> callback method.  With the default flushmode setting, adding back in
> the HibernateInterceptor to force a flush would not do it, since it
> would find the session already on the thread and would not flush on
> coming back, on that basis. You could force a flush with a FLUSH_EAGER
> setting, but then if you had multiple wrapped invocaitons, you'd flush
> on coming back from every one, not just the outer.
>
> I may be missing something; Juergen feel free to comment if the above
> is not accurate.
>
> Regards,
> Colin
>
>
> March, Andres wrote:
>
>> How does this apply to OpenSessionInViewFilter though?  The session =
is
>> always opened before a transaction begins.
>>
>>=20
>>
>>> -----Original Message-----
>>> From: spr...@li...
>>> [mailto:spr...@li...] On
>>> =20
>>
>> Behalf
>>=20
>>
>>> Of Colin Sampaleanu
>>> Sent: Friday, August 20, 2004 11:11 AM
>>> To: spr...@li...
>>> Subject: [Springframework-developer] HibernateInterceptor
>>>
>>> Juergen,
>>>
>>> If the HibernateInterceptor is currently applied before the
>>> TransactionInterceptor instead of after it, the invoke method still
>>> ensures the SessionHolder is bound to the thread, but no
>>> =20
>>
>> synchronization
>>=20
>>
>>> can be registered of course. In this case, all you get is a logged
>>>            logger.debug("Using new session for Hibernate
>>> =20
>>
>> interceptor");
>>=20
>>
>>> Do you think it's perhaps worth being a bit more explicit and
>>> =20
>>
>> mentioning
>>=20
>>
>>> that no transaction currently exists? Most of the time, unless
>>> =20
>>
>> somebody
>>=20
>>
>>> really wants to use HibernateInterceptor to create sessions outside =
of
>>> =20
>>
>> a
>>=20
>>
>>> transaction, this will be a config error, and people would be better
>>> =20
>>
>> of
>>=20
>>
>>> changing the ordering so that the session is created after the
>>> transaction, and can be synchronized...
>>>
>>> Colin
>>




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

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

Actually, to correct myself, it looks like SessionFactoryUtils does take 
care of things.

If the session has been pre-bound with no tx existing (via 
OpenSessionInViewFilter classic mode, or HibernateInterceptor), then you 
start a new transaction, then you do a SessionFactoryUtils.getSession 
(which everything goes through), this piece of code will ensure that the 
session is still registered for transaction synchronizaiton after the fact:

        SessionHolder sessionHolder = (SessionHolder) 
TransactionSynchronizationManager.getResource(sessionFactory);
        if (sessionHolder != null) {
            if 
(TransactionSynchronizationManager.isSynchronizationActive()) {
                if (allowSynchronization && 
!sessionHolder.isSynchronizedWithTransaction()) {
                    logger.debug("Registering Spring transaction 
synchronization for existing Hibernate session");
                    
TransactionSynchronizationManager.registerSynchronization(
                            new 
SpringSessionSynchronization(sessionHolder, sessionFactory, 
jdbcExceptionTranslator, false));
                    sessionHolder.setSynchronizedWithTransaction(true);
                }
                return sessionHolder.getSession();
            }

Now this is only going to happen when some code actually calls 
getSession(), so the timing will not be exactly the same as if you used 
TransactionInterceptor followed by HibernateInterceptor, but the results 
in usage should be the same for all intents and purposes...

Regards,
Colin


Colin Sampaleanu wrote:

> If you use the new mode of the OpenSessionInViewFilter where there are 
> multiple sessions, but close is deferred, then in fact there is no 
> existing session yet.
>
> If you use the old mode, with just one session, then it's probably not 
> the end of the world. The tx sync ensures a flush, and also a callback 
> into Hibernate's SessionImplementor.afterTransactionCompletion() 
> callback method.  With the default flushmode setting, adding back in 
> the HibernateInterceptor to force a flush would not do it, since it 
> would find the session already on the thread and would not flush on 
> coming back, on that basis. You could force a flush with a FLUSH_EAGER 
> setting, but then if you had multiple wrapped invocaitons, you'd flush 
> on coming back from every one, not just the outer.
>
> I may be missing something; Juergen feel free to comment if the above 
> is not accurate.
>
> Regards,
> Colin
>
>
> March, Andres wrote:
>
>> How does this apply to OpenSessionInViewFilter though?  The session is
>> always opened before a transaction begins.
>>
>>  
>>
>>> -----Original Message-----
>>> From: spr...@li...
>>> [mailto:spr...@li...] On
>>>   
>>
>> Behalf
>>  
>>
>>> Of Colin Sampaleanu
>>> Sent: Friday, August 20, 2004 11:11 AM
>>> To: spr...@li...
>>> Subject: [Springframework-developer] HibernateInterceptor
>>>
>>> Juergen,
>>>
>>> If the HibernateInterceptor is currently applied before the
>>> TransactionInterceptor instead of after it, the invoke method still
>>> ensures the SessionHolder is bound to the thread, but no
>>>   
>>
>> synchronization
>>  
>>
>>> can be registered of course. In this case, all you get is a logged
>>>            logger.debug("Using new session for Hibernate
>>>   
>>
>> interceptor");
>>  
>>
>>> Do you think it's perhaps worth being a bit more explicit and
>>>   
>>
>> mentioning
>>  
>>
>>> that no transaction currently exists? Most of the time, unless
>>>   
>>
>> somebody
>>  
>>
>>> really wants to use HibernateInterceptor to create sessions outside of
>>>   
>>
>> a
>>  
>>
>>> transaction, this will be a config error, and people would be better
>>>   
>>
>> of
>>  
>>
>>> changing the ordering so that the session is created after the
>>> transaction, and can be synchronized...
>>>
>>> Colin
>>

[Springframework-developer] -> Additional remote support

[Martin K. <Mar...@St...>]

By having a lightweight solution for simple http- and socket- 
based connections, I was planing to publish the code by
starting a project. Since I am very used to Spring and Juergen
pointed me at Spring's basic remote invocation support classes,
I was thinking if it would be possible to take my solution, do 
some extense reworking and integrate it into the spring code-base
(but also provide a possibility to extract all needed classes for
a small client api for applets/mobiles).

Since I know the advantage a socket-connection provides when
it comes to rich client <--> server (and server<-->server)
interactions, I would love to see my source-code to envolve and 
to become fully matured. It avoids polling the server to synchronize
the client's state within the server and properbly avoids some 
pesimistic locking (to tag resources) during application transactions 
and it feels well to only have to bother about business-interfaces 
rather than fuzzing with connection management.

Would anyone like to see Spring having support for socket-
remote-invocation and simple remote invocation without a
need of any additional library? 


This would free me from managing yet another project and 
I guess it can add some value to solutions applied on certain
scenarios.


Thanks,

Martin (Kersten)