springframework-developer — Spring Framework developers list

[Springframework-developer] polishing and new features

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

I've just committed extensive polishing and several new features for the =
transaction package etc, i.e. all my stuff from the last few days:

- support for Hibernate flush modes on HibernateTemplate and =
HibernateInterceptor;

- support for read-only transactions via a new =
TransactionDefinition.readOnly property: DataSourceTransactionManager =
and HibernateTransactionManager actually support this via =
Connection.setReadOnly and Hibernate's FlushMode.NEVER;

- fixed rollback exception handling: if the rollback operation itself =
throws an exception, the application exception's stacktrace gets logged =
now, and the transaction system exception thrown;

- reworked TransactionAttributeSourceEditor: supports "readOnly" =
keyword, and the other keywords in any order now (like =
"+RemoteException,readOnly,ISOLATION_READ_COMMITTERD,PROPAGATION_REQUIRED=
");

- reworked MapTransactionAttributeSource: can also be used as bean, to =
specify a "methodMap" method/attribute map that allows for bean =
references to fully configurable DefaultTransactionAttribute instances;

- application context includes via XML entities: the new =
ResourceBaseEntityResolver resolves such entities relative to the =
resource base of the application context now, allowing for splitting =
context definitions into multiple files;

- DAO base classes: the new JdbcDaoSupport, HibernateDaoSupport, and =
JdoDaoSupport classes in respective support packages can serve as =
convenient base classes for DAOs that use the templates;

- HandlerInterceptor.postHandle: the web interceptor framework supports =
postHandle now in addition to preHandle, allowing e.g. for binding user =
contexts from a session attribute to a ThreadLocal in preHandle and =
removing it again in postHandle.

Anyone who can find the time, please try the current CVS contents, and =
review the changes if you like. That's it for 0.9.1 from me.

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

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

RE: [Springframework-developer] Using PropertyEditors in JSPs

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

Hi Alef,

That sounds interesting, and it should be pretty easy to integrate. But =
for the sake of getting 0.9.1 out ASAP, I suggest to hold it back for =
after the release, just like the Tiles integration. I guess we will =
release a 0.9.2 follow-up at end of August anyway, all that stuff should =
fit in there in polished and tested versions.

BTW, I really like the extensive Javadoc that you added to some of the =
web controller classes, especially the explanations of the workflows! =
Very, very welcome :-)

Juergen


-----Original Message-----
From: Alef Arendsen (JTeam) [mailto:al...@jt...]
Sent: Wednesday, July 30, 2003 1:55 PM
To: spr...@li...
Subject: [Springframework-developer] Using PropertyEditors in JSPs



Everyone,=20

I've made an addition to the BindStatus and BindTag and added a =
TransformTag (the name is still open for discussion) I wanted to discuss =
with you before adding it.

When using <spring:bind>, a BindStatus object is instantiated for the =
path (on the command class) I'm setting in the tag. Also, any =
PropertyEditors that are associated to that field or type of property =
are consulted to get the appropriate String representation for the =
property. However, right now it's not possible to also retrieve String =
representations for any referenceData I've bound in the requestContext.

Consider the following:=20

*	I want to add a user and the user has a property called language =
(preferred language, with associated getLocale() and setLocale() =
methods)=20

*	Using a formcontroller I've returned the formBackingObject as well as =
some referenceData (in this case, a list of Locale objects from which =
the user wants to choose)=20

*	To be able to let the user choose one of the locale objects and let =
the framework set the right locale using the associated LocaleEditor, I =
need to be able to make consult the LocaleEditor for the locales in the =
list as well=20


I thought of the following to make this work. Everything enclosed by =
<spring:bind>-tags applies to a certain path of the command object and =
therefore (if applicable) an associated PropertyEditor. So anything =
enclosed by those tags could be rendered using that specific =
PropertyEditor as well.

The attached example shows the final JSP used to implement the above =
usecase.=20

Modification that need to be made to add this functionality are the =
following:=20


*	getCustomerEditor()-method to BindTag and Errors interface (and =
corresponding implementations in BindException and EscapedErrors =
(returning the appropriate editor or null if not applicable or not =
found)=20

*	Addition of transform-tag to be used inside bindtag=20


The only thing I'm not sure about is the first modification...=20

Any comments, objections or remarks about the implementation?=20

Alef=20

<<...>>=20
=3D=3D=20
JTeam B.V.=20
Donker Curtiusstraat 7-412=20
1051 JL  Amsterdam=20
T: +31 20 486 20 36=20
M: +31 6 24 11 1996=20
F: +31 84 837 00 00=20
E: al...@jt...=20
W:  <file://www.jteam.nl> www.jteam.nl=20

Re: [Springframework-developer] JavaDoc and possible issues in formcontroller

[Ken K. <kk...@kk...>]

Alef Arendsen (JTeam) wrote:

>Juergen, Rod (and mayb other people),
>
>While JavaDoc'ing parts of the mvc package (I've extensive documented about 5 or 6 of the controllers now), I came across three things in the AbstractFormController that sounded a little bit weird:
>
>I can't find the place where the command object is bound in the session in case sessionForm is set to true. I've seen this work with the SimpleFormController, but never used the AbstractFormController and since the whole RequestDataBinder stuff is kind of new to me, you might wanna have a look (line 266 or something)
>

The command object is bound in the session in AbstractFormController in 
the showForm method.

>Also, it seems like the ServletRequestDataBinder gets created, even if bindOnNewForm is false (but that's probably got to do with the previous remark) (line 272)
>  
>

A ServletRequestDataBinder (actually a DataBinder) is still needed even 
if bindOnNewForm is false. It is used to register property editors and 
and hold validation error information. If  bindOnNewForm is true, 
request params will be bound to the target by a call to 
ServletRequestDataBinder's bind method. See Petclinic's edit forms 
for bindOnNewForm == true use cases.

>Then - something slightly different - it seems like referenceData method does not get called on showing a new form, but only for the showForm()-methods that show a incorrectl validated command object (also in the same method I would have expected)
>  
>
In AbstractFormController, referenceData gets called in showForm(). showNewForm calls showForm.


>Maybe you can also have a look at the JavaDoc of Controller, AbstractController and for instance BaseCommandController and see if it's useful at all (otherwise of course I won't spend any time on it)...
>  
>
Haven't had a chance yet, but I'll take a look and get back to you.

>Cheers,
>
>Alef Arendsen
>
>  
>
Regards,
Ken

[Springframework-developer] JavaDoc and possible issues in formcontroller

[Alef A. \(JTeam\) <al...@jt...>]

Juergen, Rod (and mayb other people),

While JavaDoc'ing parts of the mvc package (I've extensive documented =
about 5 or 6 of the controllers now), I came across three things in the =
AbstractFormController that sounded a little bit weird:

I can't find the place where the command object is bound in the session =
in case sessionForm is set to true. I've seen this work with the =
SimpleFormController, but never used the AbstractFormController and =
since the whole RequestDataBinder stuff is kind of new to me, you might =
wanna have a look (line 266 or something)

Also, it seems like the ServletRequestDataBinder gets created, even if =
bindOnNewForm is false (but that's probably got to do with the previous =
remark) (line 272)

Then - something slightly different - it seems like referenceData method =
does not get called on showing a new form, but only for the =
showForm()-methods that show a incorrectl validated command object (also =
in the same method I would have expected)

Maybe you can also have a look at the JavaDoc of Controller, =
AbstractController and for instance BaseCommandController and see if =
it's useful at all (otherwise of course I won't spend any time on it)...

Cheers,

Alef Arendsen

-----Oorspronkelijk bericht-----
Van: spr...@li... =
[mailto:spr...@li...] Namens =
j=C3=BCrgen h=C3=B6ller [werk3AT]
Verzonden: Wednesday, July 30, 2003 11:34 PM
Aan: pr...@se...; Spring Developers
Onderwerp: Re: [Springframework-developer] Current release plan


Hi Trevor,
=20
First of all, good questions resp. important ones indeed!
=20
<quote>
1. What still needs to be done for 0.9.1.  From that list, what is =
currently "assigned" to someone and what still needs help? </quote>
=20
Not a lot, actually. It's mainly about polishing the Petclinic and =
Countries sample apps, and testing the current codebase in everyone's =
own projects. Everything should be assigned so far, except the latter of =
course :-)
=20
I'm currently polishing a lot of the source code. I've also added 2 new =
features that aren't committed yet but will be by the end of this week, =
namely Hibernate flush mode support on HibernateTemplate and =
HibernateInterceptor, and read-only transactions (suppressing Hibernate =
flush on the transaction level). Furthermore, I've refined =
TransactionInterceptor and MapTransactionAttributeSource a bit, =
supporting more configuration options then before.
=20
<quote>
2. Same as #1 but for the 1.0 release.
</quote>

The first 1.0 RC will involve a package name change from com.interface21 =
to org.springframework. Besides that, there won't be a lot in terms of =
new features -maybe even less than from 0.9 to 0.9.1. Rod might already =
introduce some source-level attribute stuff to the AOP framework, but =
that isn't a requirement at all. Proper JMS and Web Service support are =
candidates too but can easily wait until 1.1.
=20
<quote>
3. What is the target time-frame for the 0.9.1 and 1.0 releases =
(obviously this is sketchy since it's "volunteer" work, but "gut =
guesses" - probably from Juergen :) - based on work left is what I'm =
hoping for.  The previous estimate was the 1.0RC1 by now. </quote>
=20
0.9.1 should be out any day now. I encourage everyone to try it the =
current CVS version before the weekend. A release some time next week =
should really be achievable. We *need* to get out a follow-up release =
quickly, if just because of all the enhancements to the Hibernate =
support that have a good chance of getting adopted promptly. My =
Hibernate article in the community area and my postings to the Hibernate =
forum have already been discussing some of them for a while.

<quote>
4. From Juergen's email which I referenced, it states "As far as I see, =
we don't need additional functionality for 1.0".  The main thing holding =
me back from adopting the current code base (I'm currently using a =
personally-modified version of 0.8) is the amount and frequency of =
changes to core functionality and the public api.  Some new features or =
minor bug fixes are ok/normal, but these sweeping changes are =
destructive to production code.  How close are we to finalizing the =
public api and the core code?  Is it likely that these major changes =
should be done for 0.9.1? </quote>
=20
Maybe I'm promising too much, but I don't see any major changes on the =
horizon. The introduction of the new DTD was probably the biggest change =
in the last few months, everything else was just about slight changes to =
the public API. I agree that we need stable APIs though to allow =
production apps to rely on them without *any* hassle. 0.9.1 should be as =
stable as can be in that respect, besides the package name change for =
1.0 RC which should just involve a search-and-replace.

<quote>
To expand on my fourth question with a recommendation (hopefully it =
makes sense to everyone).  If possible we should finalize the public api =
for version 0.9.1 rather than at the 1.0RC1.  This will allow usage in =
new development without fear of incompatibilities in the next couple =
months. (...) </quote>
=20
As I indicated above, I fully agree. We've been changing our apps at =
werk3AT quite often too, it would be fine it that wouldn't be necessary =
anymore as soon as possible. And I'd really like to get you on board =
again, in terms of working with a current Spring version :-)
=20
Regards,
Juergen
N=18HS^=E9=9A=8A[){([ Zz=DE=9An =044D w%=D8=A76i=17l=11&=CA=99 =
x+ljwE=E9=A2=BBj zz0=0E'=E5=8C=96Z=C9=A9z{^=DD=AE0=DA=8Av\=13bJ DN=1Bm =
=DE=B5brK=C9=AB&=20
?=C6=B4]4 M=DA=BD Z=DE=B7N M 5J  =
jg=ED=B0=AB=ED=B0=A2=1Dz=ED=BD=96=ED=B2=97x%R=CB=A6 (G^=EC=AE=BDh  lq  =
zm=D8=B6?X (=1E~zw X b=CB=9D?  jg=1Dz=ED=BD=96=ED=B2=97

RE: [Springframework-developer] forms

[Alef A. \(JTeam\) <al...@jt...>]

Thanks Ken,

Those are exactly the things I had a look at as well when I started
using them. The only problem was that particular developer and to
getting him to understand things as well. He's like this Javadoc kind of
guy (and he's absolutely right!) and that's where the problem is
(somewhat) when it comes to those classes... Well, I've already added
some javadoc and will do some more anyway...

Alef

-----Oorspronkelijk bericht-----
Van: Ken Krebs [mailto:kk...@kk...] 
Verzonden: Wednesday, July 30, 2003 11:18 PM
Aan: al...@jt...
CC: 'Spring Developers'
Onderwerp: Re: [Springframework-developer] forms


Alef,


Alef Arendsen (JTeam) wrote:

>...
>
>Today I introduced one of our developers to Spring, because he needs to

>take over things when I'm on a holiday (next two weeks) and he had 
>major difficulties in seeing when what methods are called in the 
>controller stuff. Especially the formcontroller classes are pretty hard

>with only the JavaDoc. I'll be providing extending the JavaDoc of those

>classes a bit more, since I haven't got anything to do anyway before 
>this weekend (that's new for me, and it's wonderful ;-). Something like

>a sequence-diagram or something might be useful (but then in JavaDoc) 
>and small configuration-snippets and usage-example...
>
It is a complex process. I struggled greatly with this while working on 
Petclinic.

It's far from a complete picture, but there is some information on 
formcontrollers in the Petclinic tutorial.html file you may find useful.
See the heading "Controllers". The Petclinic forms show simple examples 
of some useful techniques.

I would also suggest looking in particular at  the source code for :
- the handleRequestInternal method in AbstractFormController
- the bindAndValidate method in BaseCommandController.

Hope this helps.

Ken

Re: [Springframework-developer] Current release plan

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

SGkgVHJldm9yLA0KIA0KRmlyc3Qgb2YgYWxsLCBnb29kIHF1ZXN0aW9ucyByZXNwLiBpbXBvcnRh
bnQgb25lcyBpbmRlZWQhDQogDQo8cXVvdGU+DQoxLiBXaGF0IHN0aWxsIG5lZWRzIHRvIGJlIGRv
bmUgZm9yIDAuOS4xLiAgRnJvbSB0aGF0IGxpc3QsIHdoYXQgaXMgY3VycmVudGx5DQoiYXNzaWdu
ZWQiIHRvIHNvbWVvbmUgYW5kIHdoYXQgc3RpbGwgbmVlZHMgaGVscD8NCjwvcXVvdGU+DQogDQpO
b3QgYSBsb3QsIGFjdHVhbGx5LiBJdCdzIG1haW5seSBhYm91dCBwb2xpc2hpbmcgdGhlIFBldGNs
aW5pYyBhbmQgQ291bnRyaWVzIHNhbXBsZSBhcHBzLCBhbmQgdGVzdGluZyB0aGUgY3VycmVudCBj
b2RlYmFzZSBpbiBldmVyeW9uZSdzIG93biBwcm9qZWN0cy4gRXZlcnl0aGluZyBzaG91bGQgYmUg
YXNzaWduZWQgc28gZmFyLCBleGNlcHQgdGhlIGxhdHRlciBvZiBjb3Vyc2UgOi0pDQogDQpJJ20g
Y3VycmVudGx5IHBvbGlzaGluZyBhIGxvdCBvZiB0aGUgc291cmNlIGNvZGUuIEkndmUgYWxzbyBh
ZGRlZCAyIG5ldyBmZWF0dXJlcyB0aGF0IGFyZW4ndCBjb21taXR0ZWQgeWV0IGJ1dCB3aWxsIGJl
IGJ5IHRoZSBlbmQgb2YgdGhpcyB3ZWVrLCBuYW1lbHkgSGliZXJuYXRlIGZsdXNoIG1vZGUgc3Vw
cG9ydCBvbiBIaWJlcm5hdGVUZW1wbGF0ZSBhbmQgSGliZXJuYXRlSW50ZXJjZXB0b3IsIGFuZCBy
ZWFkLW9ubHkgdHJhbnNhY3Rpb25zIChzdXBwcmVzc2luZyBIaWJlcm5hdGUgZmx1c2ggb24gdGhl
IHRyYW5zYWN0aW9uIGxldmVsKS4gRnVydGhlcm1vcmUsIEkndmUgcmVmaW5lZCBUcmFuc2FjdGlv
bkludGVyY2VwdG9yIGFuZCBNYXBUcmFuc2FjdGlvbkF0dHJpYnV0ZVNvdXJjZSBhIGJpdCwgc3Vw
cG9ydGluZyBtb3JlIGNvbmZpZ3VyYXRpb24gb3B0aW9ucyB0aGVuIGJlZm9yZS4NCiANCjxxdW90
ZT4NCjIuIFNhbWUgYXMgIzEgYnV0IGZvciB0aGUgMS4wIHJlbGVhc2UuDQo8L3F1b3RlPg0KDQpU
aGUgZmlyc3QgMS4wIFJDIHdpbGwgaW52b2x2ZSBhIHBhY2thZ2UgbmFtZSBjaGFuZ2UgZnJvbSBj
b20uaW50ZXJmYWNlMjEgdG8gb3JnLnNwcmluZ2ZyYW1ld29yay4gQmVzaWRlcyB0aGF0LCB0aGVy
ZSB3b24ndCBiZSBhIGxvdCBpbiB0ZXJtcyBvZiBuZXcgZmVhdHVyZXMgLW1heWJlIGV2ZW4gbGVz
cyB0aGFuIGZyb20gMC45IHRvIDAuOS4xLiBSb2QgbWlnaHQgYWxyZWFkeSBpbnRyb2R1Y2Ugc29t
ZSBzb3VyY2UtbGV2ZWwgYXR0cmlidXRlIHN0dWZmIHRvIHRoZSBBT1AgZnJhbWV3b3JrLCBidXQg
dGhhdCBpc24ndCBhIHJlcXVpcmVtZW50IGF0IGFsbC4gUHJvcGVyIEpNUyBhbmQgV2ViIFNlcnZp
Y2Ugc3VwcG9ydCBhcmUgY2FuZGlkYXRlcyB0b28gYnV0IGNhbiBlYXNpbHkgd2FpdCB1bnRpbCAx
LjEuDQogDQo8cXVvdGU+DQozLiBXaGF0IGlzIHRoZSB0YXJnZXQgdGltZS1mcmFtZSBmb3IgdGhl
IDAuOS4xIGFuZCAxLjAgcmVsZWFzZXMgKG9idmlvdXNseQ0KdGhpcyBpcyBza2V0Y2h5IHNpbmNl
IGl0J3MgInZvbHVudGVlciIgd29yaywgYnV0ICJndXQgZ3Vlc3NlcyIgLSBwcm9iYWJseQ0KZnJv
bSBKdWVyZ2VuIDopIC0gYmFzZWQgb24gd29yayBsZWZ0IGlzIHdoYXQgSSdtIGhvcGluZyBmb3Iu
ICBUaGUgcHJldmlvdXMNCmVzdGltYXRlIHdhcyB0aGUgMS4wUkMxIGJ5IG5vdy4NCjwvcXVvdGU+
DQogDQowLjkuMSBzaG91bGQgYmUgb3V0IGFueSBkYXkgbm93LiBJIGVuY291cmFnZSBldmVyeW9u
ZSB0byB0cnkgaXQgdGhlIGN1cnJlbnQgQ1ZTIHZlcnNpb24gYmVmb3JlIHRoZSB3ZWVrZW5kLiBB
IHJlbGVhc2Ugc29tZSB0aW1lIG5leHQgd2VlayBzaG91bGQgcmVhbGx5IGJlIGFjaGlldmFibGUu
IFdlICpuZWVkKiB0byBnZXQgb3V0IGEgZm9sbG93LXVwIHJlbGVhc2UgcXVpY2tseSwgaWYganVz
dCBiZWNhdXNlIG9mIGFsbCB0aGUgZW5oYW5jZW1lbnRzIHRvIHRoZSBIaWJlcm5hdGUgc3VwcG9y
dCB0aGF0IGhhdmUgYSBnb29kIGNoYW5jZSBvZiBnZXR0aW5nIGFkb3B0ZWQgcHJvbXB0bHkuIE15
IEhpYmVybmF0ZSBhcnRpY2xlIGluIHRoZSBjb21tdW5pdHkgYXJlYSBhbmQgbXkgcG9zdGluZ3Mg
dG8gdGhlIEhpYmVybmF0ZSBmb3J1bSBoYXZlIGFscmVhZHkgYmVlbiBkaXNjdXNzaW5nIHNvbWUg
b2YgdGhlbSBmb3IgYSB3aGlsZS4NCg0KPHF1b3RlPg0KNC4gRnJvbSBKdWVyZ2VuJ3MgZW1haWwg
d2hpY2ggSSByZWZlcmVuY2VkLCBpdCBzdGF0ZXMgIkFzIGZhciBhcyBJIHNlZSwgd2UNCmRvbid0
IG5lZWQgYWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5IGZvciAxLjAiLiAgVGhlIG1haW4gdGhpbmcg
aG9sZGluZyBtZQ0KYmFjayBmcm9tIGFkb3B0aW5nIHRoZSBjdXJyZW50IGNvZGUgYmFzZSAoSSdt
IGN1cnJlbnRseSB1c2luZyBhDQpwZXJzb25hbGx5LW1vZGlmaWVkIHZlcnNpb24gb2YgMC44KSBp
cyB0aGUgYW1vdW50IGFuZCBmcmVxdWVuY3kgb2YgY2hhbmdlcw0KdG8gY29yZSBmdW5jdGlvbmFs
aXR5IGFuZCB0aGUgcHVibGljIGFwaS4gIFNvbWUgbmV3IGZlYXR1cmVzIG9yIG1pbm9yIGJ1Zw0K
Zml4ZXMgYXJlIG9rL25vcm1hbCwgYnV0IHRoZXNlIHN3ZWVwaW5nIGNoYW5nZXMgYXJlIGRlc3Ry
dWN0aXZlIHRvDQpwcm9kdWN0aW9uIGNvZGUuICBIb3cgY2xvc2UgYXJlIHdlIHRvIGZpbmFsaXpp
bmcgdGhlIHB1YmxpYyBhcGkgYW5kIHRoZSBjb3JlDQpjb2RlPyAgSXMgaXQgbGlrZWx5IHRoYXQg
dGhlc2UgbWFqb3IgY2hhbmdlcyBzaG91bGQgYmUgZG9uZSBmb3IgMC45LjE/DQo8L3F1b3RlPg0K
IA0KTWF5YmUgSSdtIHByb21pc2luZyB0b28gbXVjaCwgYnV0IEkgZG9uJ3Qgc2VlIGFueSBtYWpv
ciBjaGFuZ2VzIG9uIHRoZSBob3Jpem9uLiBUaGUgaW50cm9kdWN0aW9uIG9mIHRoZSBuZXcgRFRE
IHdhcyBwcm9iYWJseSB0aGUgYmlnZ2VzdCBjaGFuZ2UgaW4gdGhlIGxhc3QgZmV3IG1vbnRocywg
ZXZlcnl0aGluZyBlbHNlIHdhcyBqdXN0IGFib3V0IHNsaWdodCBjaGFuZ2VzIHRvIHRoZSBwdWJs
aWMgQVBJLiBJIGFncmVlIHRoYXQgd2UgbmVlZCBzdGFibGUgQVBJcyB0aG91Z2ggdG8gYWxsb3cg
cHJvZHVjdGlvbiBhcHBzIHRvIHJlbHkgb24gdGhlbSB3aXRob3V0ICphbnkqIGhhc3NsZS4gMC45
LjEgc2hvdWxkIGJlIGFzIHN0YWJsZSBhcyBjYW4gYmUgaW4gdGhhdCByZXNwZWN0LCBiZXNpZGVz
IHRoZSBwYWNrYWdlIG5hbWUgY2hhbmdlIGZvciAxLjAgUkMgd2hpY2ggc2hvdWxkIGp1c3QgaW52
b2x2ZSBhIHNlYXJjaC1hbmQtcmVwbGFjZS4NCg0KPHF1b3RlPg0KVG8gZXhwYW5kIG9uIG15IGZv
dXJ0aCBxdWVzdGlvbiB3aXRoIGEgcmVjb21tZW5kYXRpb24gKGhvcGVmdWxseSBpdCBtYWtlcw0K
c2Vuc2UgdG8gZXZlcnlvbmUpLiAgSWYgcG9zc2libGUgd2Ugc2hvdWxkIGZpbmFsaXplIHRoZSBw
dWJsaWMgYXBpIGZvcg0KdmVyc2lvbiAwLjkuMSByYXRoZXIgdGhhbiBhdCB0aGUgMS4wUkMxLiAg
VGhpcyB3aWxsIGFsbG93IHVzYWdlIGluIG5ldw0KZGV2ZWxvcG1lbnQgd2l0aG91dCBmZWFyIG9m
IGluY29tcGF0aWJpbGl0aWVzIGluIHRoZSBuZXh0IGNvdXBsZSBtb250aHMuICguLi4pDQo8L3F1
b3RlPg0KIA0KQXMgSSBpbmRpY2F0ZWQgYWJvdmUsIEkgZnVsbHkgYWdyZWUuIFdlJ3ZlIGJlZW4g
Y2hhbmdpbmcgb3VyIGFwcHMgYXQgd2VyazNBVCBxdWl0ZSBvZnRlbiB0b28sIGl0IHdvdWxkIGJl
IGZpbmUgaXQgdGhhdCB3b3VsZG4ndCBiZSBuZWNlc3NhcnkgYW55bW9yZSBhcyBzb29uIGFzIHBv
c3NpYmxlLiBBbmQgSSdkIHJlYWxseSBsaWtlIHRvIGdldCB5b3Ugb24gYm9hcmQgYWdhaW4sIGlu
IHRlcm1zIG9mIHdvcmtpbmcgd2l0aCBhIGN1cnJlbnQgU3ByaW5nIHZlcnNpb24gOi0pDQogDQpS
ZWdhcmRzLA0KSnVlcmdlbg0K

RE : [Springframework-developer] Petclinic, ant.bat, and Weird issue trying to run unit tests

[JP P. <jp....@ti...>]

As the messages passed out of the list, I inform here that I sent the =
files to Lars and he updated the german file. This is now committed and =
used in the live demo.

Thanks once more to Lars.

Regards,
Jean-Pierre

-----Message d'origine-----
De : spr...@li... =
[mailto:spr...@li...] De la =
part de j=C3=BCrgen h=C3=B6ller [werk3AT]
Envoy=C3=A9 : mercredi 30 juillet 2003 20:56
=C3=80 : Lars Fischer; spr...@li...
Objet : Re: [Springframework-developer] Petclinic, ant.bat, and Weird =
issue trying to run unit tests

Obviously, I could too, being a German speaker living in Austria... I =
just didn't take the time for it, too busy developing core features ;-) =
So I'm glad if you do a proper translation, Lars!
=20
Juergen
=20
=20

	-----Urspr=C3=BCngliche Nachricht-----=20
	Von: Lars Fischer [mailto:lar...@gm...]=20
	Gesendet: Di 29.07.2003 14:56=20
	An: spr...@li...=20
	Cc:=20
	Betreff: Re: RE : [Springframework-developer] Petclinic, ant.bat, and =
Weird issue trying to run unit tests
=09
=09

	See below.
=09
	> <juergen>
	> Jean-Pierre and Ken: Please re-test Countries and Petclinic (better
	> after the TLD name change), especially the versions that the release
	> target in our Spring Ant script generates. Simply unzip the generated
	> spring-framework-0.9.1.zip somewhere and "act like a user".
	> </juergen>
	>
	> I have now updated 'Countries'.
	> Adding the support of HSql, I discovered that it doesn't support the
	> batch mode. Having so an opportunity to handle a backend exception,
	> logged, but solved by an alternative way for the job. The end user is
	> not aware of the issue as long as it is solved.
	>
	> So, just if anyone with german skills could take a look at the german
	> Countries properties files. On the TSS thread, someone found the =
german
	> translation "funny" and discovered that large bunches were made with
	> Googgle help.
=09
	That was me :-) I can translate the files for you. You can send them =
via
	email.
=09
	Regards
	Lars
=09
=09
=09
	-------------------------------------------------------
	This SF.Net email sponsored by: Free pre-built ASP.NET sites including
	Data Reports, E-commerce, Portals, and Forums are available now.
	Download today and enter to win an XBOX or Visual Studio .NET.
	=
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/=
01
	_______________________________________________
	Springframework-developer mailing list
	Spr...@li...
	https://lists.sourceforge.net/lists/listinfo/springframework-developer
=09

NHzn=C8=B44i=11xjjz
z=C9=AE\JNr =D3=BD Jjzqz~z jz

Re: [Springframework-developer] forms

[Ken K. <kk...@kk...>]

Alef,


Alef Arendsen (JTeam) wrote:

>...
>
>Today I introduced one of our developers to Spring, because he needs to
>take over things when I'm on a holiday (next two weeks) and he had major
>difficulties in seeing when what methods are called in the controller
>stuff. Especially the formcontroller classes are pretty hard with only
>the JavaDoc. I'll be providing extending the JavaDoc of those classes a
>bit more, since I haven't got anything to do anyway before this weekend
>(that's new for me, and it's wonderful ;-). Something like a
>sequence-diagram or something might be useful (but then in JavaDoc) and
>small configuration-snippets and usage-example...
>
It is a complex process. I struggled greatly with this while working on 
Petclinic.

It's far from a complete picture, but there is some information on 
formcontrollers in the Petclinic tutorial.html file you may find useful.
See the heading "Controllers". The Petclinic forms show simple examples 
of some useful techniques.

I would also suggest looking in particular at  the source code for :
- the handleRequestInternal method in AbstractFormController
- the bindAndValidate method in BaseCommandController.

Hope this helps.

Ken

Re: [Springframework-developer] Current release plan

[<tri...@tr...>]

Trevor & All,

> 1. What still needs to be done for 0.9.1.  From that list, what is currently
> "assigned" to someone and what still needs help?

I have nothing additional.

> 2. Same as #1 but for the 1.0 release.

I'll be adding functionality to the JDBC package.  Returning resultset from a
stored procedure is the main addition.  This should all be additional
functionality and not break the existing API.

> 3. What is the target time-frame for the 0.9.1 and 1.0 releases (obviously
> this is sketchy since it's "volunteer" work, but "gut guesses" - probably
> from Juergen :) - based on work left is what I'm hoping for.  The previous
> estimate was the 1.0RC1 by now.

Once 0.9.1 is out (any day now AFAIK), I would suggest a 4-6 weeks "beta"
testing period.  I'm hoping to use parts of the framework in new projects the
next couple of months.  Tha would put the 1.0 release somewhere in September.

> 
> To expand on my fourth question with a recommendation (hopefully it makes
> sense to everyone).  If possible we should finalize the public api for
> version 0.9.1 rather than at the 1.0RC1.  This will allow usage in new
> development without fear of incompatibilities in the next couple months.

100% agreement - I'm pretty much in the same boat.  If we keep the API stable I
can start using it on new development.

Thomas

RE: [Springframework-developer] Current release plan

[Alef A. \(JTeam\) <al...@jt...>]

I read Juergen's mail and saw the following passage: ...and provide
short essays on resource/transaction management and Spring web MVC vs
Struts (as announced, I already have drafts).

Today I introduced one of our developers to Spring, because he needs to
take over things when I'm on a holiday (next two weeks) and he had major
difficulties in seeing when what methods are called in the controller
stuff. Especially the formcontroller classes are pretty hard with only
the JavaDoc. I'll be providing extending the JavaDoc of those classes a
bit more, since I haven't got anything to do anyway before this weekend
(that's new for me, and it's wonderful ;-). Something like a
sequence-diagram or something might be useful (but then in JavaDoc) and
small configuration-snippets and usage-example...

As far as additions to the MVC are concerned, I don't think much is
needed to be able to build a decent webapp. Anybody interested in
getting the TilesView(Resolver) in before the 1.0 release (might be a
nice feature to show the pluggability and stuff)??

Alef Arendsen



-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
Trevor Cook
Verzonden: Wednesday, July 30, 2003 9:24 PM
Aan: Spring Developers
Onderwerp: [Springframework-developer] Current release plan


I haven't seen this addressed recently, so I'm just curious on the
current status.  The most recent "detailed" info I could find was from
Juergen's email on June 25
(http://sourceforge.net/mailarchive/message.php?msg_id=5357667), just
before the 0.9 release.  I have a few questions, partly to figure out if
there's anything I'll be able to help with now (before September :) )
and also to gauge what to use for a project I'm starting.  Anyway,
here's my list of questions :)

1. What still needs to be done for 0.9.1.  From that list, what is
currently "assigned" to someone and what still needs help? 2. Same as #1
but for the 1.0 release. 3. What is the target time-frame for the 0.9.1
and 1.0 releases (obviously this is sketchy since it's "volunteer" work,
but "gut guesses" - probably from Juergen :) - based on work left is
what I'm hoping for.  The previous estimate was the 1.0RC1 by now. 4.
From Juergen's email which I referenced, it states "As far as I see, we
don't need additional functionality for 1.0".  The main thing holding me
back from adopting the current code base (I'm currently using a
personally-modified version of 0.8) is the amount and frequency of
changes to core functionality and the public api.  Some new features or
minor bug fixes are ok/normal, but these sweeping changes are
destructive to production code.  How close are we to finalizing the
public api and the core code?  Is it likely that these major changes
should be done for 0.9.1?

To expand on my fourth question with a recommendation (hopefully it
makes sense to everyone).  If possible we should finalize the public api
for version 0.9.1 rather than at the 1.0RC1.  This will allow usage in
new development without fear of incompatibilities in the next couple
months. Personally this means I can use the current code base for
development which will benefit me with the new features and bug fixes,
it would benefit Spring by additional testing and use, and (on a
personal note) it would allow me to start contributing again sooner (I
don't have "spare time" until September, but I can use some "work time"
once I'm using the current Spring version rather than 0.8).  I believe
I'm not alone in this, so hopefully a "mostly finalized" core will
attract a bunch of new developers (either users or
contributors) as well.  Obviously this finalization would allow changes
where required due to major gaffes and bugs (which I don't expect there
will be too many of, but there's always some :) ).

Trevor D. Cook



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01
/01
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Petclinic, ant.bat, and Weird issue trying to run unit tests

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

T2J2aW91c2x5LCBJIGNvdWxkIHRvbywgYmVpbmcgYSBHZXJtYW4gc3BlYWtlciBsaXZpbmcgaW4g
QXVzdHJpYS4uLiBJIGp1c3QgZGlkbid0IHRha2UgdGhlIHRpbWUgZm9yIGl0LCB0b28gYnVzeSBk
ZXZlbG9waW5nIGNvcmUgZmVhdHVyZXMgOy0pIFNvIEknbSBnbGFkIGlmIHlvdSBkbyBhIHByb3Bl
ciB0cmFuc2xhdGlvbiwgTGFycyENCiANCkp1ZXJnZW4NCiANCiANCg0KCS0tLS0tVXJzcHLDvG5n
bGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBMYXJzIEZpc2NoZXIgW21haWx0bzpsYXJzLmZp
c2NoZXJAZ214cHJvLm5ldF0gDQoJR2VzZW5kZXQ6IERpIDI5LjA3LjIwMDMgMTQ6NTYgDQoJQW46
IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KCUNjOiAN
CglCZXRyZWZmOiBSZTogUkUgOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gUGV0Y2xpbmlj
LCBhbnQuYmF0LCBhbmQgV2VpcmQgaXNzdWUgdHJ5aW5nIHRvIHJ1biB1bml0IHRlc3RzDQoJDQoJ
DQoNCglTZWUgYmVsb3cuDQoJDQoJPiA8anVlcmdlbj4NCgk+IEplYW4tUGllcnJlIGFuZCBLZW46
IFBsZWFzZSByZS10ZXN0IENvdW50cmllcyBhbmQgUGV0Y2xpbmljIChiZXR0ZXINCgk+IGFmdGVy
IHRoZSBUTEQgbmFtZSBjaGFuZ2UpLCBlc3BlY2lhbGx5IHRoZSB2ZXJzaW9ucyB0aGF0IHRoZSBy
ZWxlYXNlDQoJPiB0YXJnZXQgaW4gb3VyIFNwcmluZyBBbnQgc2NyaXB0IGdlbmVyYXRlcy4gU2lt
cGx5IHVuemlwIHRoZSBnZW5lcmF0ZWQNCgk+IHNwcmluZy1mcmFtZXdvcmstMC45LjEuemlwIHNv
bWV3aGVyZSBhbmQgImFjdCBsaWtlIGEgdXNlciIuDQoJPiA8L2p1ZXJnZW4+DQoJPg0KCT4gSSBo
YXZlIG5vdyB1cGRhdGVkICdDb3VudHJpZXMnLg0KCT4gQWRkaW5nIHRoZSBzdXBwb3J0IG9mIEhT
cWwsIEkgZGlzY292ZXJlZCB0aGF0IGl0IGRvZXNuJ3Qgc3VwcG9ydCB0aGUNCgk+IGJhdGNoIG1v
ZGUuIEhhdmluZyBzbyBhbiBvcHBvcnR1bml0eSB0byBoYW5kbGUgYSBiYWNrZW5kIGV4Y2VwdGlv
biwNCgk+IGxvZ2dlZCwgYnV0IHNvbHZlZCBieSBhbiBhbHRlcm5hdGl2ZSB3YXkgZm9yIHRoZSBq
b2IuIFRoZSBlbmQgdXNlciBpcw0KCT4gbm90IGF3YXJlIG9mIHRoZSBpc3N1ZSBhcyBsb25nIGFz
IGl0IGlzIHNvbHZlZC4NCgk+DQoJPiBTbywganVzdCBpZiBhbnlvbmUgd2l0aCBnZXJtYW4gc2tp
bGxzIGNvdWxkIHRha2UgYSBsb29rIGF0IHRoZSBnZXJtYW4NCgk+IENvdW50cmllcyBwcm9wZXJ0
aWVzIGZpbGVzLiBPbiB0aGUgVFNTIHRocmVhZCwgc29tZW9uZSBmb3VuZCB0aGUgZ2VybWFuDQoJ
PiB0cmFuc2xhdGlvbiAiZnVubnkiIGFuZCBkaXNjb3ZlcmVkIHRoYXQgbGFyZ2UgYnVuY2hlcyB3
ZXJlIG1hZGUgd2l0aA0KCT4gR29vZ2dsZSBoZWxwLg0KCQ0KCVRoYXQgd2FzIG1lIDotKSBJIGNh
biB0cmFuc2xhdGUgdGhlIGZpbGVzIGZvciB5b3UuIFlvdSBjYW4gc2VuZCB0aGVtIHZpYQ0KCWVt
YWlsLg0KCQ0KCVJlZ2FyZHMNCglMYXJzDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgU0YuTmV0IGVtYWlsIHNw
b25zb3JlZCBieTogRnJlZSBwcmUtYnVpbHQgQVNQLk5FVCBzaXRlcyBpbmNsdWRpbmcNCglEYXRh
IFJlcG9ydHMsIEUtY29tbWVyY2UsIFBvcnRhbHMsIGFuZCBGb3J1bXMgYXJlIGF2YWlsYWJsZSBu
b3cuDQoJRG93bmxvYWQgdG9kYXkgYW5kIGVudGVyIHRvIHdpbiBhbiBYQk9YIG9yIFZpc3VhbCBT
dHVkaW8gLk5FVC4NCglodHRwOi8vYXNwbmV0LmNsaWNrLXVybC5jb20vZ28vcHNhMDAxMDAwMDNh
dmUvZGlyZWN0O2F0LmFzcG5ldF8wNzIzMDNfMDEvMDENCglfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFp
bGluZyBsaXN0DQoJU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5u
ZXQNCglodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdm
cmFtZXdvcmstZGV2ZWxvcGVyDQoJDQoNCg==

[Springframework-developer] Current release plan

[Trevor C. <pr...@se...>]

I haven't seen this addressed recently, so I'm just curious on the current
status.  The most recent "detailed" info I could find was from Juergen's
email on June 25
(http://sourceforge.net/mailarchive/message.php?msg_id=5357667), just before
the 0.9 release.  I have a few questions, partly to figure out if there's
anything I'll be able to help with now (before September :) ) and also to
gauge what to use for a project I'm starting.  Anyway, here's my list of
questions :)

1. What still needs to be done for 0.9.1.  From that list, what is currently
"assigned" to someone and what still needs help?
2. Same as #1 but for the 1.0 release.
3. What is the target time-frame for the 0.9.1 and 1.0 releases (obviously
this is sketchy since it's "volunteer" work, but "gut guesses" - probably
from Juergen :) - based on work left is what I'm hoping for.  The previous
estimate was the 1.0RC1 by now.
4. From Juergen's email which I referenced, it states "As far as I see, we
don't need additional functionality for 1.0".  The main thing holding me
back from adopting the current code base (I'm currently using a
personally-modified version of 0.8) is the amount and frequency of changes
to core functionality and the public api.  Some new features or minor bug
fixes are ok/normal, but these sweeping changes are destructive to
production code.  How close are we to finalizing the public api and the core
code?  Is it likely that these major changes should be done for 0.9.1?

To expand on my fourth question with a recommendation (hopefully it makes
sense to everyone).  If possible we should finalize the public api for
version 0.9.1 rather than at the 1.0RC1.  This will allow usage in new
development without fear of incompatibilities in the next couple months.
Personally this means I can use the current code base for development which
will benefit me with the new features and bug fixes, it would benefit Spring
by additional testing and use, and (on a personal note) it would allow me to
start contributing again sooner (I don't have "spare time" until September,
but I can use some "work time" once I'm using the current Spring version
rather than 0.8).  I believe I'm not alone in this, so hopefully a "mostly
finalized" core will attract a bunch of new developers (either users or
contributors) as well.  Obviously this finalization would allow changes
where required due to major gaffes and bugs (which I don't expect there will
be too many of, but there's always some :) ).

Trevor D. Cook

[Springframework-developer] Spring promotion via Hibernate

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

Someone asked a simple question about DAOs for Hibernate...

http://sourceforge.net/forum/forum.php?thread_id=3D909428&forum_id=3D1286=
38

I seem to have started a fire ;-) Notice *2 different people* =
recommending Spring!

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

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

RE : [Springframework-developer] petclinic, hsqldb, & jboss

[Jean-Pierre <jp...@jp...>]

Rajeev,

 

>>> One more thing.  There is no need to comment out the log4j
configuration listener for spring samples running under JBOSS.  Just use
the attached log4j.properties file.

 

I tested your log4j file, but it's no miracle. It is carefully written
to well start. Unfortunately, the issue rests when undeploying the
application: all JBoss logging are definitively stopped. The server
itself can go wrong in this case, but it's not the case with your log4j
file. It seems it's the best possible, but I believe like others that
with JBoss the logging is better set in JBoss configuration files.  

So I will provide your file but let the note for commenting out the
listener.

 

>>> I actually used the jboss supplied hsqldb-ds.xml file instead of
hsql-petclinic-ds.xml.  I modified the petclinic build.properties to use
the port 1701 for hsql, and the jboss-web.xml to use the
"java:/DefaultDS" as the jndi name.  This eliminates the step of having
to copy a separate hsql-petclinic-ds.xml file in the Jboss deploy dir.
The petclinic application works fine with this setting.  However, I am
still getting the JBOSS "MessageCache" error.

 

Yes, your proposal simplifies the installation by the use of DefaultDS.
Just as you made, the port must be set to 1701 in build.properties. I
will make changes.

 

For the "MessageCache" error, we will certainly have to live with for
the 0.9.1. I have no more time to fix in time.

 

Regards,

Jean-Pierre

Re: [Springframework-developer] petclinic, hsqldb, & jboss

[Rajeev K. <Ra...@cu...>]

Hi Jean-Pierre,

I actually used the jboss supplied hsqldb-ds.xml file instead of =
hsql-petclinic-ds.xml.  I modified the petclinic build.properties to use =
the port 1701 for hsql, and the jboss-web.xml to use the =
"java:/DefaultDS" as the jndi name.  This eliminates the step of having =
to copy a separate hsql-petclinic-ds.xml file in the Jboss deploy dir. =
The petclinic application works fine with this setting.  However, I am =
still getting the JBOSS "MessageCache" error.

Rajeev
  ----- Original Message -----=20
  From: JP Pawlak=20
  To: 'Rajeev Kaul'=20
  Sent: Tuesday, July 29, 2003 12:12 AM
  Subject: RE : [Springframework-developer] petclinic, hsqldb, & jboss


  Hi Rajeev,



  Thanks for your feedback !



  1)

  , ObjectName: jboss.mq:service=3DMessageCache state: FAILED

  I used the same port number as the standard standalone HSql like =
Thomas used for Tomcat. However, this port seems be used by jboss.mq. As =
long as you don't use the messaging service,  you will not have trouble =
with this, except the message you reported.=20



  For fixing: change the port number from 9001 to 1701 in =
hsql-petclinic-ds.xml as well as inhsql.url in build.properties.

  I didn't make it for having the same port for JBoss and others AS.





  2)

  1.  The petclinic build does not automatically copy the =
hsql-petclinic-ds.xml to the deploy directory.

              It would complicate more the build process as the version =
of JBoss should be asked in the properties. The xxx-ds.xml files are =
different for jboss 3.0.xx and 3.2.xx.

  3)

  2. The web.xml does not contain the following information:

  <resource-ref>

  <res-ref-name>jdbc/petclinicHSQL</res-ref-name>

  <res-type>javax.sql.DataSource</res-type>

  <res-auth>Container</res-auth>

  </resource-ref>

  <resource-ref>

  <res-ref-name>jdbc/petclinicMYSQL</res-ref-name>

  <res-type>javax.sql.DataSource</res-type>

  <res-auth>Container</res-auth>

  </resource-ref>



              Right ! I added it.



  4)

  3.  The "DROP TABLE" sql commands cause a problem, when you run the =
script the first time.  I had to comment them out from the build.xml in =
the db dir for the 1st build. In subsequent builds it worked fine.

   I splitted drop and creation tasks, but using the attribute =
onerror=3D "continue" for these sql tasks.



  Regards,

  Jean-Pierre

Re: [Springframework-developer] equals/hashCode for entities

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

jürgen höller [werk3AT] wrote:

>Everyone,
>
>A rather general problem that I've been wondering about for a while: "equals"/"hashCode" implementation for entities with an externally determined ID.
>
>I've repeatedly discovered issues with primary-key-based implementations of the both. The root cause is adding an entity to a HashSet *before* setting its ID, e.g. when using a MySQL autoincrement column as primary key with Hibernate. Example: Filling a parent folder including some children and then saving them all in one go. A "contains" or "remove" call on the children collection will fail then, as the hash code has changed while the object was in the collection.
>
>Of course, HashSet states that this is illegal, but how to avoid this? It's especially tricky with m:n associations, e.g. between parents and children. No matter how you load such an object tree, some entities will always get added to a collection in a not fully initialized state, potentially incurring hash code failure when the ID hasn't been set yet. This not only arises with persistence tools like Hibernate but also with remoting tools like Hessian.
>
>I see various solutions for the problem:
>
>- Reinitializing the HashSet after the change: This solves the create-then-save issue, but seems like a hack and doesn't address the mutual m:n issue.
>  
>
Can you clarify what you mean when you say it doesn't address the mutual 
m:n issue?   Main issue that I see here is really hibernate. If 
Hibernate and the collections it manages are happy, then I don't care 
about some transient collection elsewhere that has the original instance 
of the object with the empty id field (since I don't consider that the 
same object any longer anyways). But I think with some (a lot of) code 
Hibernate could track persistent collections (it already does insert a 
bytecode modified version of each collection anyways, so has some 
collection handling), track whether an object can potentially be a 
member of a collection (which it can do based on the mapping data it 
has), and then on assigning an ID go through all the candidate 
collections and try to pull out the old instance if it exists and 
reinsert it properly.

I will say, after this conversation, GUIDs are starting to look pretty 
good :-)  Too bad about legacy tables though...

Re: [Springframework-developer] equals/hashCode for entities

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

jürgen höller [werk3AT] wrote:

><quote>
>So, we make a hashCode with some smarts. First time hashcode is called,
>- if id is null/zero, then hashCode will forever return the same value, 
>which is the same for all class instances. Inefficient, but doesn't 
>cause Sets to barf.
>- but if is not-null/zero and hashCode has never been called while id 
>was null/zero, then hashCode will retun a value based on the id. This 
>means that loaded entities loaded form the db are treated efficiently.
>
>Still not that great in terms of efficiency for new entities, but 
>efficient for old entities.
></quote>
>
>Interesting idea - a hashCode implementation that tracks if it has already been called with an empty ID... So "contains" and "remove" will work even after saving, but unfortunately only for this very instance. Calling "contains" with a freshly loaded instance (and the previously saved one in the collection) will still fail, as the freshly loaded instance will return an ID-based hash code that will not match the one in the collection.
>
Hmm, I think your point shows that this technique is somewhat dangerous. 
I think it might break Hibernate's saveOrUpdate functionality in some 
cases. You can not have a new object which is added to a session 
(therefore it had an empty id and was added as such to the collection, 
and then come along with a transient version of the same object (which 
was built up in a different order (ie not added to a collection before 
the id was set), coming in as a child  in a collection inside a parent 
object, and call saveOrUpdate reliably. That is, Hibernate would know if 
the object needs to be saved or updated ok, but on an update would not 
be able to get the same initial instance to update.

bummer...

>
><quote>
>Also, there is still an issue with any collection (ie not HashSet) that 
>uses 'equals', since that is going to change when the id changes.
></quote>
>
>But that doesn't matter as such a collection will just call "equals" on *lookup*, not on *addition*. It will always find an entity, as long as "equals" can deal with the current state. That's not the case with HashSet: The hash code of an object is determined within the "add" method, and fixed from there on.
>
>Juergen
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

RE: [Springframework-developer] equals/hashCode for entities

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

<quote>
So, we make a hashCode with some smarts. First time hashcode is called,
- if id is null/zero, then hashCode will forever return the same value,=20
which is the same for all class instances. Inefficient, but doesn't=20
cause Sets to barf.
- but if is not-null/zero and hashCode has never been called while id=20
was null/zero, then hashCode will retun a value based on the id. This=20
means that loaded entities loaded form the db are treated efficiently.

Still not that great in terms of efficiency for new entities, but=20
efficient for old entities.
</quote>

Interesting idea - a hashCode implementation that tracks if it has =
already been called with an empty ID... So "contains" and "remove" will =
work even after saving, but unfortunately only for this very instance. =
Calling "contains" with a freshly loaded instance (and the previously =
saved one in the collection) will still fail, as the freshly loaded =
instance will return an ID-based hash code that will not match the one =
in the collection.

<quote>
Also, there is still an issue with any collection (ie not HashSet) that=20
uses 'equals', since that is going to change when the id changes.
</quote>

But that doesn't matter as such a collection will just call "equals" on =
*lookup*, not on *addition*. It will always find an entity, as long as =
"equals" can deal with the current state. That's not the case with =
HashSet: The hash code of an object is determined within the "add" =
method, and fixed from there on.

Juergen

Re: [Springframework-developer] equals/hashCode for entities

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

jürgen höller [werk3AT] wrote:

>Everyone,
>
>A rather general problem that I've been wondering about for a while: "equals"/"hashCode" implementation for entities with an externally determined ID.
>
>I've repeatedly discovered issues with primary-key-based implementations of the both. The root cause is adding an entity to a HashSet *before* setting its ID, e.g. when using a MySQL autoincrement column as primary key with Hibernate. Example: Filling a parent folder including some children and then saving them all in one go. A "contains" or "remove" call on the children collection will fail then, as the hash code has changed while the object was in the collection.
>
>Of course, HashSet states that this is illegal, but how to avoid this? It's especially tricky with m:n associations, e.g. between parents and children. No matter how you load such an object tree, some entities will always get added to a collection in a not fully initialized state, potentially incurring hash code failure when the ID hasn't been set yet. This not only arises with persistence tools like Hibernate but also with remoting tools like Hessian.
>
>I see various solutions for the problem:
>
>- Reinitializing the HashSet after the change: This solves the create-then-save issue, but seems like a hack and doesn't address the mutual m:n issue.
>
>- Use the standard "equals"/"hashCode" implementations: This solves both issues, but object equality is based on object identity then, which isn't suitable e.g. for web applications that might store one entity in the HTTP session and load another freshly, maybe wanting to compare their parent.
>
>- "equals" based on the primary key, but "hashCode" returning the same value for all instances of a class: This is valid, as "hashCode" has to return the same value if "equals" is true but just *should* return distinct values if not equal. As "hashCode" doesn't depend on the primary key anymore, both issues are solved.
>
>The latter has the disadvantage that it doesn't care for the performance of hash lookups. Looking up such an entity in a hash table is linear like with an unsorted array. But typically this isn't a big deal, as most collections will just contain a limited number of objects anyway, e.g. assocation collections in an object tree.
>
>We've currently adopted the latter approach, but I'm not 100% convinced that there isn't a better solution for the problem. What do you think?
>  
>
How about having a smart hashCode() function? That is, we do know 
certain behavioral invariants w/regards to the domain objects we persist 
(for example with Hibernate).

When the object is created new and then saved to the persistent store:
- object is created
- id is null or zero
- object is added to some collection (hashCode will be used)
- object is persisted to the db, changing the id
- id never changes from then on

When the object is loaded from the db:
- object is created
- id is not null or zero
- id never changes from then on
- object is added to some collection (hashCode will be used)

So, we make a hashCode with some smarts. First time hashcode is called,
- if id is null/zero, then hashCode will forever return the same value, 
which is the same for all class instances. Inefficient, but doesn't 
cause Sets to barf.
- but if is not-null/zero and hashCode has never been called while id 
was null/zero, then hashCode will retun a value based on the id. This 
means that loaded entities loaded form the db are treated efficiently.

Still not that great in terms of efficiency for new entities, but 
efficient for old entities.

Also, there is still an issue with any collection (ie not HashSet) that 
uses 'equals', since that is going to change when the id changes.

>Juergen
>
>
>DI Jürgen Höller
>Senior System Architect
>______________________________________
>
>werk3ATS - division systementwicklung
>part of werk3AT internetmedien oeg
>
>europaplatz 4
>A - 4020 linz
>
>t.  +43 (0) 732 71 65 29 502
>f.  +43 (0) 732 71 65 29 3
>jue...@we...
>www.werk3at.com
>______________________________________
>werk3ATS - WIR ENTWICKELN ERFOLG
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

RE: [Springframework-developer] Re: HibernateTemplate enhancement

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

SG1tbSwgcmlnaHQuIEEgSGliZXJuYXRlVGVtcGxhdGUoc2Vzc2lvbkZhY3RvcnksYWxsb3dDcmVh
dGUpIGNvbnN0cnVjdG9yIG1ha2VzIHNlbnNlIC0gSSdsbCBhZGQgaXQuDQoNCllvdSBkb24ndCBu
ZWVkIHRvIGtlZXAgdGhlIEhpYmVybmF0ZVRlbXBsYXRlIGluc3RhbmNlIGluIHRoZSBjb250ZXh0
LiBZb3UgY291bGQgc3RvcmUgaXQgaW4gYSBtZW1iZXIgdmFyaWFibGUgb2YgeW91ciBEQU8sIGZv
ciBleGFtcGxlLCBpbml0aWFsaXppbmcgaXQgaW4gYSBEQU8uc2V0U2Vzc2lvbkZhY3RvcnkgY2Fs
bCAobm8gbWF0dGVyIGlmIHBvcHVsYXRlZCBtYW51YWxseSBvciBieSB0aGUgY29udGV4dCkgYW5k
IHJldXNpbmcgaXQgaW4gYWxsIG9mIHRoZSBEQU8ncyBtZXRob2RzLg0KDQpCVFcsIEkgaGF2ZSBh
bHJlYWR5IGFkZGVkIGEgSGliZXJuYXRlRGFvU3VwcG9ydCBiYXNlIGNsYXNzIGJ1dCBub3QgY29t
bWl0dGVkIHlldCwgdG9nZXRoZXIgd2l0aCBKZG9EYW9TdXBwb3J0IGFuZCBKZGJjRGFvU3VwcG9y
dCBvbmVzLiBCYXNpY2FsbHksIEhpYmVybmF0ZURhb1N1cHBvcnQgcHJvdmlkZXMgZXhhY3RseSB0
aGUgYWJvdmU6IGluaXRpYWxpemF0aW9uIGNvZGUgZm9yIGEgInNlc3Npb25GYWN0b3J5IiBiZWFu
IHByb3BlcnR5LCB3aXRoIGEgcHJvdGVjdGVkIGdldEhpYmVybmF0ZVRlbXBsYXRlKCkgZm9yIHN1
YmNsYXNzZXMuDQoNClN1Y2ggYSBEQU8gYmFzZSBjbGFzcyBpcyB2ZXJ5IHNpbXBsZSBidXQgdXNl
ZnVsIElNTyAtIHdlIHVzZSBpdCBmb3IgSGliZXJuYXRlIERBT3MgaW4gYWxsIG9mIG91ciBwcm9q
ZWN0cy4gT2YgY291cnNlLCB0aGlzIGlzbid0IGEgcmVxdWlyZW1lbnQgYXQgYWxsLCBlc3BlY2lh
bGx5IGlmIHlvdSdkIGxpa2UgdG8gZGVyaXZlIGZyb20gYW5vdGhlciBiYXNlIGNsYXNzLg0KDQpS
ZWdhcmRzLA0KSnVlcmdlbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBD
b2xpbiBTYW1wYWxlYW51IFttYWlsdG86Y29saW5tbDFAZXhpcy5jb21dDQpTZW50OiBUdWVzZGF5
LCBKdWx5IDI5LCAyMDAzIDQ6MjIgUE0NClRvOiBqw7xyZ2VuIGjDtmxsZXIgW3dlcmszQVRdOw0K
c3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNClN1YmplY3Q6
IFJlOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gUmU6IEhpYmVybmF0ZVRlbXBsYXRlDQpl
bmhhbmNlbWVudA0KDQoNClNvdXJjZWZvcmdlIGFub24gYWNjZXNzIGZpbmFsbHkgY2F1Z2h0IHVw
IHdpdGggdGhlc2UgY2hhbmdlcywgc28gSSB3YXMgDQphYmxlIHRvIHB1bGwgdGhlbSBkb3duLg0K
DQpHb29kIHN0dWZmLiBIb3dldmVyLCBpcyB0aGVyZSBhbnkgcGFydGljdWxhciByZWFzb24geW91
IGRpZG4ndCBtYWtlIGEgDQpjb25zdHJ1Y3RvciBvZiBIaWJlcm5hdGVUZW1wbGF0ZSB3aGljaCBp
bmNsdWRlcyB0aGUgYWxsb3dDcmVhdGUgZmxhZyBpbiANCml0IChzYW1lIGFzIFNlc3Npb25GYWN0
b3J5VXRpbHMuZ2V0U2Vzc2lvbigpKT8NCg0KVGhlcmUgYXJlIGEgbnVtYmVyIG9mIGNhc2VzIHdo
ZXJlIEhpYmVybmF0ZVRlbXBsYXRlIGNhbiBiZSB1c2VkIGluIGEgDQpvbmUtbGluZSBmYXNoaW9u
LCBhcw0KICByZXR1cm4gbmV3IEhpYmVybmF0ZVRlbXBsYXRlKF9zZXNzaW9uRmFjdG9yeSkubG9h
ZCh0aGVDbGFzcywgaWQpOw0KYnV0IGlmIHlvdSBuZWVkIHRvIHNldCB0aGUgYWxsb3dDcmVhdGUg
ZmxhZywgdGhhdCBiZWNvbWVzDQogIEhpYmVybmF0ZVRlbXBsYXRlIGh0ID0gbmV3IEhpYmVybmF0
ZVRlbXBsYXRlKF9zZXNzaW9uRmFjdG9yeSk7DQogIGh0LnNldEFsbG93Q3JlYXRlKGZhbHNlKTsN
CiAgcmV0dXJuIGh0LmxvYWQodGhlQ2xhc3MsIGlkKTsNCg0KcXVpdGUgYSBiaXQgbW9yZSB2ZXJi
b3NlLiBOb3cgSSBrbm93IHRoZSBIaWJlcm5hdGVUZW1wbGF0ZSBpbnN0YW5jZSANCml0c2VsZiBj
YW4gY29tZSBvdXQgb2YgdGhlIGNvbnRleHQsIGJ1dCB0aGF0J3Mgbm90IG5lY2Vzc2FyaWx5IGFs
d2F5cyANCnRoZSBiZXN0IGNob2ljZS4uLg0KDQpSZWdhcmRzLA0KQ29saW4NCg0KDQpqw7xyZ2Vu
IGjDtmxsZXIgW3dlcmszQVRdIHdyb3RlOg0KDQo+Q29saW4sDQo+IA0KPkkndmUganVzdCBhZGRl
ZCBhbiAiYWxsb3dDcmVhdGUiIHByb3BlcnR5IHRvIGJvdGggSGliZXJuYXRlVGVtcGxhdGUgYW5k
IEpkb1RlbXBsYXRlLCB0byBzdXBwb3J0IHRoZSB1c2UgY2FzZSB5b3UndmUgb3V0bGluZWQuDQo+
IA0KPkkndmUgYWxzbyBmaW5pc2hlZCBlbnRpdHkgaW50ZXJjZXB0b3Igc3VwcG9ydDogTG9jYWxT
ZXNzaW9uRmFjdG9yeUJlYW4sIEhpYmVybmF0ZVRlbXBsYXRlLCBIaWJlcm5hdGVJbnRlcmNlcHRv
ciwgYW5kIEhpYmVybmF0ZVRyYW5zYWN0aW9uTWFuYWdlciBhbGwgZmVhdHVyZSBhICJlbnRpdHlJ
bnRlcmNlcHRvciIgcHJvcGVydHkgbm93LCB0YWtlbiBhIG5ldC5zZi5oaWJlcm5hdGUuSW50ZXJj
ZXB0b3IgdG8gYXBwbHkgYXQgdGhlIHJlc3BlY3RpdmUgbGV2ZWwuDQo+IA0KPkZ1cnRoZXJtb3Jl
LCBMb2NhbFNlc3Npb25GYWN0b3J5QmVhbiBhbmQgTG9jYWxQZXJzaXN0ZW5jZU1hbmFnZXJGYWN0
b3J5QmVhbiBzdXBwb3J0ICJuZXdDb25maWd1cmF0aW9uIiwgIm5ld1Nlc3Npb25GYWN0b3J5Iiwg
YW5kICJuZXdQZXJzaXN0ZW5jZU1hbmFnZXJGYWN0b3J5IiBmYWN0b3J5IGFuZCBjdXN0b21pemF0
aW9uIGhvb2tzIG5vdy4gVGhpcyBzaG91bGQgYWxsb3cgdG8gdXNlIGFueSBzcGVjaWZpY2FsbHkg
cHJlY29uZmlndXJlZCBpbnN0YW5jZSBvciBjdXN0b20gc3ViY2xhc3Mgb2YgdGhlc2UuDQo+IA0K
PlJlZ2FyZHMsDQo+SnVlcmdlbg0KPiANCj4gDQo+DQo+CS0tLS0tVXJzcHLDvG5nbGljaGUgTmFj
aHJpY2h0LS0tLS0gDQo+CVZvbjogQ29saW4gU2FtcGFsZWFudSBbbWFpbHRvOmNvbGlubWwxQGV4
aXMuY29tXSANCj4JR2VzZW5kZXQ6IE1vIDI4LjA3LjIwMDMgMDM6MjcgDQo+CUFuOiBzcHJpbmdm
cmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCANCj4JQ2M6IGrDvHJnZW4g
aMO2bGxlciBbd2VyazNBVF0gDQo+CUJldHJlZmY6IEhpYmVybmF0ZVRlbXBsYXRlIGVuaGFuY2Vt
ZW50DQo+CQ0KPgkNCj4NCj4JSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gZW5oYW5jZSBI
aWJlcm5hdGVUZW1wbGF0ZSB0byB3b3JrIGluIGENCj4JbW9kZSBzdWNoIHRoYXQgaXQgZG9lc24n
dCBjcmVhdGUgdGhlIHNlc3Npb24gaWYgaXQgaXNuJ3QgYWxyZWFkeSBib3VuZA0KPglvbiB0aGUg
dGhyZWFkLiBUaGF0IGlzLCB0aGVyZSB3b3VsZCBiZSBhIG5ldyBjb25zdHJ1Y3RvciB3aGljaCBt
aXJyb3JzDQo+CXRoZSBTZXNzaW9uRmFjdG9yeVV0aWxzLmdldFNlc3Npb24oZmFjdG9yeSwgYm9v
bGVhbikgbWV0aG9kIHNpZ25hdHVyZS4NCj4JDQo+CVdpdGggdGhlIG5ldyBjb252ZW5pZW5jZSBt
ZXRob2RzIGFuZCB0aGUgd3JhcHBpbmcgb2YgSGliZXJuYXRlDQo+CWV4Y2VwdGlvbnMsIEkgdGhp
bmsgSGliZXJuYXRlVGVtcGxhdGUgaXMgdXNlZnVsIGluIHNvbWUgY2FzZXMgZXZlbiB3aGVuDQo+
CUhpYmVybmF0ZUludGVyY2VwdG9yIGlzIHVzZWQgdG8gYWN0dWFsbHkgYmluZCB0aGUgc2Vzc2lv
biB0byB0aGUgdGhyZWFkLg0KPglIb3dldmVyLCBpbiB0aGUgbGF0dGVyIGNhc2UsIEkgYW0gc29t
ZXdoYXQgd29ycnJpZWQgYWJvdXQgdXNpbmcNCj4JSGliZXJuYXRlVGVtcGxhdGUgYXMgaXQgbm93
IGV4aXN0cyBzaW5jZSB0aGVyZSBpcyB0aGUgZGFuZ2VyIG9mIG1pc3NpbmcNCj4JdGhlIGludGVy
Y2VwdG9yIGluIG9uZSBwbGFjZSBhbmQgYWNjaWRlbnRhbGx5IGF1dG8gY3JlYXRpbmcgdGhlIHNl
c3Npb24uDQo+CQ0KPgkNCj4JDQo+CQ0KPgkNCj4NCj5OGD9IU14/6ZqKWyk/eyg/P1s/Wj96Pz9u
6KW0BD80RD/XrD93JT/Ypz82P2kXPz8/bBE/Jj8/P3g/Kz8/bGp3RT8/Pz8/P2o/P3p6MA4/Jz8/
Pz8/WsmpP3p7Xj8/MD92P1wTPz8/Yj8/StudPz9EThttPz/asj/etT9icks/Pz8mPw0KPj8/xrQ/
XTQ/Tdq9P92KPz8/P1o/P963Tj8/TT8/PzVKPz8HP2pnPz8/HXo/Pz8/Pz94JT8/Uj8/Pz8/2pk/
KD9HXj8/aD8/Pz9sPz8/cT8/Bz96P20/Pz8/WD8/Pyg/Px5+Pz96dz8/WD8/Pz8/Yj8/Pz8/Pwc/
amc/Pz8dej8/DQo+DQoNCg0K

Re: [Springframework-developer] Re: HibernateTemplate enhancement

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

Sourceforge anon access finally caught up with these changes, so I was 
able to pull them down.

Good stuff. However, is there any particular reason you didn't make a 
constructor of HibernateTemplate which includes the allowCreate flag in 
it (same as SessionFactoryUtils.getSession())?

There are a number of cases where HibernateTemplate can be used in a 
one-line fashion, as
  return new HibernateTemplate(_sessionFactory).load(theClass, id);
but if you need to set the allowCreate flag, that becomes
  HibernateTemplate ht = new HibernateTemplate(_sessionFactory);
  ht.setAllowCreate(false);
  return ht.load(theClass, id);

quite a bit more verbose. Now I know the HibernateTemplate instance 
itself can come out of the context, but that's not necessarily always 
the best choice...

Regards,
Colin


jürgen höller [werk3AT] wrote:

>Colin,
> 
>I've just added an "allowCreate" property to both HibernateTemplate and JdoTemplate, to support the use case you've outlined.
> 
>I've also finished entity interceptor support: LocalSessionFactoryBean, HibernateTemplate, HibernateInterceptor, and HibernateTransactionManager all feature a "entityInterceptor" property now, taken a net.sf.hibernate.Interceptor to apply at the respective level.
> 
>Furthermore, LocalSessionFactoryBean and LocalPersistenceManagerFactoryBean support "newConfiguration", "newSessionFactory", and "newPersistenceManagerFactory" factory and customization hooks now. This should allow to use any specifically preconfigured instance or custom subclass of these.
> 
>Regards,
>Juergen
> 
> 
>
>	-----Ursprüngliche Nachricht----- 
>	Von: Colin Sampaleanu [mailto:col...@ex...] 
>	Gesendet: Mo 28.07.2003 03:27 
>	An: spr...@li... 
>	Cc: jürgen höller [werk3AT] 
>	Betreff: HibernateTemplate enhancement
>	
>	
>
>	I think it would be useful to enhance HibernateTemplate to work in a
>	mode such that it doesn't create the session if it isn't already bound
>	on the thread. That is, there would be a new constructor which mirrors
>	the SessionFactoryUtils.getSession(factory, boolean) method signature.
>	
>	With the new convenience methods and the wrapping of Hibernate
>	exceptions, I think HibernateTemplate is useful in some cases even when
>	HibernateInterceptor is used to actually bind the session to the thread.
>	However, in the latter case, I am somewhat worrried about using
>	HibernateTemplate as it now exists since there is the danger of missing
>	the interceptor in one place and accidentally auto creating the session.
>	
>	
>	
>	
>	
>
>N?HS^?隊[)?{(??[?Z?z??n襴?4D?׬?w%?ا?6?i???l?&???x?+??ljwE??????j??zz0?'?????Zɩ?z{^??0?v?\???b??J۝??DNm??ڲ?޵?brK???&?
>??ƴ?]4?Mڽ?݊????Z??޷N??M???5J???jg???z??????x%??R?????ڙ?(?G^??h????l???q???z?m????X???(??~??zw??X?????b???????jg???z??
>

[Springframework-developer] equals/hashCode for entities

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

Everyone,

A rather general problem that I've been wondering about for a while: =
"equals"/"hashCode" implementation for entities with an externally =
determined ID.

I've repeatedly discovered issues with primary-key-based implementations =
of the both. The root cause is adding an entity to a HashSet *before* =
setting its ID, e.g. when using a MySQL autoincrement column as primary =
key with Hibernate. Example: Filling a parent folder including some =
children and then saving them all in one go. A "contains" or "remove" =
call on the children collection will fail then, as the hash code has =
changed while the object was in the collection.

Of course, HashSet states that this is illegal, but how to avoid this? =
It's especially tricky with m:n associations, e.g. between parents and =
children. No matter how you load such an object tree, some entities will =
always get added to a collection in a not fully initialized state, =
potentially incurring hash code failure when the ID hasn't been set yet. =
This not only arises with persistence tools like Hibernate but also with =
remoting tools like Hessian.

I see various solutions for the problem:

- Reinitializing the HashSet after the change: This solves the =
create-then-save issue, but seems like a hack and doesn't address the =
mutual m:n issue.

- Use the standard "equals"/"hashCode" implementations: This solves both =
issues, but object equality is based on object identity then, which =
isn't suitable e.g. for web applications that might store one entity in =
the HTTP session and load another freshly, maybe wanting to compare =
their parent.

- "equals" based on the primary key, but "hashCode" returning the same =
value for all instances of a class: This is valid, as "hashCode" has to =
return the same value if "equals" is true but just *should* return =
distinct values if not equal. As "hashCode" doesn't depend on the =
primary key anymore, both issues are solved.

The latter has the disadvantage that it doesn't care for the performance =
of hash lookups. Looking up such an entity in a hash table is linear =
like with an unsorted array. But typically this isn't a big deal, as =
most collections will just contain a limited number of objects anyway, =
e.g. assocation collections in an object tree.

We've currently adopted the latter approach, but I'm not 100% convinced =
that there isn't a better solution for the problem. What do you think?

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

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

Re: RE : [Springframework-developer] Petclinic, ant.bat, and Weird issue trying to run unit tests

[Lars F. <lar...@gm...>]

See below.

> <juergen>
> Jean-Pierre and Ken: Please re-test Countries and Petclinic (better 
> after the TLD name change), especially the versions that the release 
> target in our Spring Ant script generates. Simply unzip the generated 
> spring-framework-0.9.1.zip somewhere and "act like a user".
> </juergen>
> 
> I have now updated 'Countries'.
> Adding the support of HSql, I discovered that it doesn't support the
> batch mode. Having so an opportunity to handle a backend exception,
> logged, but solved by an alternative way for the job. The end user is
> not aware of the issue as long as it is solved.
> 
> So, just if anyone with german skills could take a look at the german
> Countries properties files. On the TSS thread, someone found the german
> translation "funny" and discovered that large bunches were made with
> Googgle help.

That was me :-) I can translate the files for you. You can send them via
email.

Regards
Lars

RE: [Springframework-user] Re: [Springframework-developer] BeansErrorHandler: missing method

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

SSd2ZSBiZWVuIHdvcmtpbmcgb24gMS40LjFfMDEgb24gV2luIDJLIGZvciBoYWxmIGEgeWVhciBh
dCB3b3JrLCBhbmQgb3VyIGZvcm1lciBCZWFuc0Vycm9ySGFuZGxlciB3b3JrZWQgZm9yIG1lIChz
dGlsbCBkaWQgdG9tb3Jyb3cgbW9ybmluZykuLi4gSSdtIHVzaW5nIDEuNC4xXzAzIGF0IGhvbWUs
IHdvcmtzIHRoZXJlIHRvby4gQW55d2F5LCBhcyB5b3Ugc2FpZCwgaXQgc2hvdWxkIHdvcmsgaW4g
YW55IGVudmlyb25tZW50IG5vdy4NCg0KQW5kIEkndmUgYWx3YXlzIHRob3VnaHQgdGhhdCBKYXZh
IGhhZCBhIHN0YWJsZSBsYW5ndWFnZSBpbXBsZW1lbnRhdGlvbiA7LSkNCg0KSnVlcmdlbg0KDQoN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSb2QgSm9obnNvbiBbbWFpbHRvOnJv
ZC5qb2huc29uQGludGVyZmFjZTIxLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjksIDIwMDMg
OTozOCBBTQ0KVG86IGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF07DQpzcHJpbmdmcmFtZXdvcmst
ZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KU3ViamVjdDogUmU6IFtTcHJpbmdmcmFt
ZXdvcmstdXNlcl0gUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXQ0KQmVhbnNFcnJvckhh
bmRsZXI6IG1pc3NpbmcgbWV0aG9kDQoNCg0KSXQgZmFpbGVkIGZvciBtZSB3aXRoIDEuNC4xXzAx
IG9uIFdpbiAySy4gQW55d2F5LCBzaG91bGQgYmUgbm8gbW9yZSBwcm9ibGVtcw0Kbm93Lg0KDQot
LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiasO8cmdlbiBow7ZsbGVyIFt3ZXJr
M0FUXSIgPGp1ZXJnZW4uaG9lbGxlckB3ZXJrM2F0LmNvbT4NClRvOiAiUm9kIEpvaG5zb24iIDxy
b2Quam9obnNvbkBpbnRlcmZhY2UyMS5jb20+Ow0KPHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJA
bGlzdHMuc291cmNlZm9yZ2UubmV0Pg0KQ2M6IDxzcHJpbmdmcmFtZXdvcmstdXNlckBsaXN0cy5z
b3VyY2Vmb3JnZS5uZXQ+DQpTZW50OiBUdWVzZGF5LCBKdWx5IDI5LCAyMDAzIDg6MTEgQU0NClN1
YmplY3Q6IFJFOiBbU3ByaW5nZnJhbWV3b3JrLXVzZXJdIFJlOiBbU3ByaW5nZnJhbWV3b3JrLWRl
dmVsb3Blcl0NCkJlYW5zRXJyb3JIYW5kbGVyOiBtaXNzaW5nIG1ldGhvZA0KDQoNCj4gRnVubmls
eSBlbm91Z2gsIGl0IGFjdHVhbGx5ICpkb2VzKiB3b3JrIG9uIEpESyAxLjQuMV8wMSwgMS40LjFf
MDIsDQoxLjQuMV8wMywgMS4zLjFfMDQsIGFuZCAxLjMuMV8wNywgb24gV2luZG93cyAyMDAwIGFu
ZCBYUC4gQW55d2F5LCB1c2luZyBhbg0Kb3duIGxvZ2dlciBpbnN0YW5jZSB0byBhdm9pZCBhbnkg
aGFzc2xlIGlzIGRlZmluaXRlbHkgdGhlIGJlc3Qgb3B0aW9uLg0KPg0KPiBKdWVyZ2VuDQo+DQo+
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJvZCBKb2huc29uIFttYWls
dG86cm9kLmpvaG5zb25AaW50ZXJmYWNlMjEuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDI5
LCAyMDAzIDg6NTMgQU0NCj4gVG86IGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF07DQo+IHNwcmlu
Z2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQo+IENjOiBzcHJpbmdm
cmFtZXdvcmstdXNlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj4gU3ViamVjdDogUmU6IFtTcHJp
bmdmcmFtZXdvcmstdXNlcl0gUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXQ0KPiBCZWFu
c0Vycm9ySGFuZGxlcjogbWlzc2luZyBtZXRob2QNCj4NCj4NCj4gPiBGb3IgY3VyaW9zaXR5J3Mg
c2FrZSwgZG8geW91IGtub3cgd2hhdCAqZXhhY3RseSogY2FuIGNhdXNlIHRoZSBpbm5lcg0KY2xh
c3MNCj4gbG9nZ2VyIGFjY2VzcyB0byBmYWlsPyBJcyB0aGlzIGEgVk0gcmVzcGVjdGl2ZWx5IGJ5
dGVjb2RlIGlzc3VlPw0KPg0KPiBOb3QgcmVhbGx5LiBJdCdzIHN0cmFuZ2UgdGhhdCBpdCBjb21w
aWxlcyBidXQgZG9lc24ndCB3b3JrLiBJIGd1ZXNzIGl0J3MgYQ0KPiBWTSBpc3N1ZS4gSSB0aGlu
ayB0aGF0IHJlbHlpbmcgb24gYSBwcm90ZWN0ZWQgaW5oZXJpdGVkIG91dGVyIGNsYXNzDQp2YXJp
YWJsZQ0KPiBpcyBhY3R1YWxseSBpbGxlZ2FsIGluIEphdmEuIEkganVzdCBkb24ndCB1bmRlcnN0
YW5kIHdoeSBpdCBjb21waWxlZC4NCj4NCj4gSSdtIHBvc3RpbmcgdG8gdGhlIHRocmVhZC4NCj4N
Cj4NCj4NCg0KDQo=

Re: [Springframework-user] Re: [Springframework-developer] BeansErrorHandler: missing method

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

It failed for me with 1.4.1_01 on Win 2K. Anyway, should be no more problems
now.

----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: "Rod Johnson" <rod...@in...>;
<spr...@li...>
Cc: <spr...@li...>
Sent: Tuesday, July 29, 2003 8:11 AM
Subject: RE: [Springframework-user] Re: [Springframework-developer]
BeansErrorHandler: missing method


> Funnily enough, it actually *does* work on JDK 1.4.1_01, 1.4.1_02,
1.4.1_03, 1.3.1_04, and 1.3.1_07, on Windows 2000 and XP. Anyway, using an
own logger instance to avoid any hassle is definitely the best option.
>
> Juergen
>
>
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Tuesday, July 29, 2003 8:53 AM
> To: jürgen höller [werk3AT];
> spr...@li...
> Cc: spr...@li...
> Subject: Re: [Springframework-user] Re: [Springframework-developer]
> BeansErrorHandler: missing method
>
>
> > For curiosity's sake, do you know what *exactly* can cause the inner
class
> logger access to fail? Is this a VM respectively bytecode issue?
>
> Not really. It's strange that it compiles but doesn't work. I guess it's a
> VM issue. I think that relying on a protected inherited outer class
variable
> is actually illegal in Java. I just don't understand why it compiled.
>
> I'm posting to the thread.
>
>
>