springframework-developer — Spring Framework developers list

Re: [Springframework-developer] XML bean references

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

On Monday 20 October 2003 16:50, j=C3=BCrgen h=C3=B6ller [werk3AT] wrote:

> I'm inclined to go the "bean" / "local" / "external"(deprecated) route
> again... Votes please! Given this decision, I vote for "local" instead of
> "internal"; Colin obviously does too.

It's likely I'm missing something obvious, maybe due to not using Spring on=
=20
projects where I'd see the advantage of this, but what exactly is the=20
real-world advantage of having the distinction?  I know it lends weight to=
=20
the DTD validation for local beans, which means my IDE can tell me that I=20
made a typo in a <ref bean=3D"foo" /> tag before the logging output does, b=
ut=20
is there something more?  Or is there more of an advantage than I can see=20
from the additional validation - performance, or caching or something?

Just a bit curious since part of the discussion relates to what is the=20
simplest concept and it seems as though it would be simplest all round if=20
<ref bean=3D"foo" /> was the only attribute, which worked for both local an=
d=20
external.

If there are good reasons to keep the distinction, then I'm +1 for the=20
bean/local option.

TIA for any insight..

Regards,

=2D-=20

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

Re: [Springframework-developer] Petclinic Hibernate implementation

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

jürgen höller [werk3AT] wrote:

>Thomas, Trevor,
>
>>oes Hibernate use a different ID strategy for different databases?  I think
>>    
>>
>what is implemented in the Petclinic is a strategy that would work the same
>across different databses as long as there is a MaxValueIncrementer implementation.
>
>I intend to configure Hibernate to use "identity" for all databases. Setting the correct Hibernate dialect will lead to "auto_increment" on MySQL and "identity" on HSQL then. In terms of the data model, this simply means dropping the sequence tables and defining the id columns as "auto_increment" respectively "identity" in the DDL scripts.
>
>Sure, MaxValueIncrementer adopts a very generic approach that will work on any database, even if it doesn't support such a thing like identity columns. The disadvantage is that the mechanism is normally not native to the database and thus somewhat tied to the application.
>
>>f we change the Petclinic JDBC implementation to use identity columns, then we
>>    
>>
>need to figure out how to run the insert and subsequent query to retrieve the id
>using the same connection whether we are in a transaction or not.
>
>This is very similar with MySQL and HSQL: You simply run the insert without specifying a value for the id field, and query "select last_insert_id()" respectively "call identity()" afterwards (I've looked up the latter in Hibernate's MySQLDialect and HSQLDialect implementations). Petclinic already uses MySQLJdbcClinic and HSQLJdbcClinic subclasses; it should be easy to encapsulate the id-fetching query there.
>
>Of course, the range of possible Petclinic JDBC implementations will then be bound to identity-supporting databases. According to the Hibernate docs, those are "DB2, MySQL, MS SQL Server, Sybase and HypersonicSQL". Oracle is notably absent; I think we can live with Petclinic not running on Oracle, if we can allow for a dynamic switch between JDBC and Hibernate on both MySQL and HSQL that way!
>  
>
I guess you are trying to make the exact same thing run under both 
Hibernate and JDBC, but if you are willing to say the Oracle DB only 
works with the Hibernate version (and handle the DDL separately too), 
then you can easily do that by just using 'native' as the Hibernate type...

RE: [Springframework-developer] Petclinic Hibernate implementation

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

Juergen,

> According to what I found out about MySQL, "last_insert_id" returns the last
> used id on the same connection and is thus transactionally safe. Don't know
> about HSQL, but I frankly don't mind for sample purposes.
> 

HSQL has IDENTITY() which returns the last identity value for the connection -
so the functionality is basically the same.  We just have to make sure that we
use the same connection - an sqlUpdate followed by an sqlQuery might not
gurantee this.  I have been thinking about creating a datasource that makes the
same conection available for a series of database interactions (with
supressClose turned on) - like a temporary SingleConnectionDataSource created
from a pooled DataSource.  

What do you think of a MultipleUseConnectionDataSource that gets a DataSource
passed in the constructor.  This MultipleUseConnectionDataSource could then be
passed in to several sqlUpdate or sqlQuery objects and deflect any attempts to
close it during this sequence of database interaction.  Finally we would call
destroy() on the MultipleUseConnectionDataSource causing the connection to be
returned to the pool.

Thomas

RE: [Springframework-developer] XML bean references

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

+1 for "bean/local"

I don't mind the different "pairs" ("bean/local", "bean/internal", =
"bean/external"), but having a triad (such as the previously proposed =
"bean/external/internal") will be really confusing.  As long as the 3rd =
is deprecated (and hopefully removed after a suitable amount of time) it =
makes sense, just don't have 3 regularly used names.  My 2 cents.

Trevor


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=C3=BCrgen h=C3=B6ller [werk3AT]
Sent: October 20, 2003 11:51 AM
To: spr...@li...
Subject: RE: [Springframework-developer] XML bean references


Colin,

Hmmm, you've got a point there. I also like "local" more; I just =
considered "internal" as the opposite for "external". You're right that =
"external" will probably not get used anymore; the only important =
different is referencing a strictly local bean versus any bean.

I'm inclined to go the "bean" / "local" / "external"(deprecated) route =
again... Votes please! Given this decision, I vote for "local" instead =
of "internal"; Colin obviously does too.

Juergen


-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...]
Sent: Monday, October 20, 2003 4:50 PM
To: spr...@li...
Subject: Re: [Springframework-developer] XML bean references


I'm ok with this, although it's getting more verbose. I also wonder if=20
"external" would ever be used in the future at all? That is, would=20
somebody ever be interested in validating that something is only=20
external? Perhaps people would indeed use it due to the principal of=20
least surprise (that is, if you use only 'internal' and 'external', then =

you always know exactly where your beans are coming from. But then why=20
use the 'ambiguous 'bean' at all?).

If you assume people would probably _not_ use 'external', then I think=20
your original 'local' is nicer name for bean id references that are=20
local to the file only.

i.e.:

- <ref bean=3D"..."/> can reference any bean by any name (equal to =
current "external", similar to current "bean" but without XML idref =
check);
- <ref local=3D"..."/> can reference a bean id in the same XML file =
(equal to the current "bean">
- <ref external=3D"..."/> deprecated, not enocuraged to be used, and =
documented minimally.

If you _do_ think people would actually have a need for and use =
"external" on an ongoing basis, then probably "internal" as the opposite =
does make more sense than "local"...

Regards,

Colin


jrgen h ller [werk3AT] wrote:

>Third and hopefully final attempt at proper attribute naming, with =
"internal" instead of "local" (as it matches its counterpart "external" =
better):=20
>
>- <ref bean=3D"..."/> can reference any bean by any name (equal to =
current "external", similar to current "bean" but without XML idref =
check);
>=20
>- <ref external=3D"..."/> stays as it is for the time being, but in its =
final incarnation, it should check that the reference is really outside =
the current XML file;
>=20
>- <ref internal=3D"..."/> can reference a bean id in the same XML file =
(equal to the formerly proposed "bean-id", with an XML idref check).
>
>Request for comments again :-)
>
>Juergen
>
>
>-----Original Message-----
>From: Colin Sampaleanu [mailto:col...@ex...]
>Sent: Monday, October 20, 2003 12:53 AM
>To: jrgen h ller [werk3AT]
>Cc: spr...@li...
>Subject: Re: [Springframework-developer] XML bean references
>
>
>I think this would work, and is probably the least ambiguous.
>
>jrgen h ller [werk3AT] wrote:
>
> =20
>
>>Colin, Rod,
>>
>>You're right regarding the term "external" for a different XML file, =
not only a different context. On second thought, I consider "bean-id" =
unclear too, as beans in other XML files also have an "id". Thus, a =
slightly refined suggestion:
>>
>>- <ref bean=3D"..."/> can reference any bean by any name (equal to =
current "external", similar to current "bean" but without XML idref =
check);
>>
>>- <ref external=3D"..."/> stays as it is for the time being, but in =
its final incarnation, it should check that the reference is really =
outside the current XML file;
>>
>>- <ref local=3D"..."/> can reference a bean id in the same XML file =
(equal to the formerly proposed "bean-id", with an XML idref check).
>>
>>That's probably as easy to explain as possible: "bean" is the general =
one that can reference anything, "external" is for beans outside the =
current file, "local" for beans inside the current file -- and it's =
still backward-compatible. What do you think?
>>
>>Juergen
>>
>>
>>
>>	-----Ursprngliche Nachricht-----=20
>>	Von: Colin Sampaleanu [mailto:col...@ex...]=20
>>	Gesendet: So 19.10.2003 16:20=20
>>	An: j rgen hller [werk3AT]=20
>>	Cc: spr...@li...=20
>>	Betreff: Re: [Springframework-developer] XML bean references
>>=09
>>=09
>>
>>	j rgen hller [werk3AT] wrote:
>>=09
>>	>Everybody,
>>	>
>>	>On the occasion of allowing a single application context to be =
loaded from multiple XML files, I've reconsidered a detail of our XML =
syntax: The "ref" tag currently has two different attributes:
>>	>- "bean" to reference a bean in the same application context via its =
id attribute (the XML id);
>>	>- "external" to reference a bean in a parent context.
>>	>The latter can basically address any bean, be it in the same context =
or a parent, an id or an alias name.
>>	>
>>	>The main rationale behind the "bean"/"external" separation was =
simply separating between XML validation of id refs (by the XML parser) =
and referencing any kind of name (validated by the bean factory). The =
latter was mainly necessary for referencing beans outside of the current =
XML file, at that time a parent context. In the mean time, a single =
context can be defined by multiple XML files; thus I don't consider the =
"bean"/"external" naming appropriate anymore.
>>	>
>>	>Instead, let me suggest different attribute names:
>>	>- keep a "bean" attribute to reference *any* kind of name, be it id =
or alias, just like the current "external" attribute;
>>	>- introduce a new "bean-id" attribute to reference a bean in the =
same XML file via its XML id, like the current "bean" attribute.
>>	>
>>	>If we keep the "external" attribute for the moment as an equivalent =
of the proposed "bean" attribute, this would be fully compatible with =
existing bean definition files. Of course, "bean" attributes would not =
get validated by the XML parser anymore, but that would not break the =
files in any way. "external" attributes would still work too, the same =
as before.
>>	>
>>	>We should recommend migrating to the new pattern though, i.e.:
>>	>- rename "bean" to "bean-id";
>>	>- rename "external" to "bean".
>>	>That should be easy to do; and as the old pattern still works, there =
is no need to migrate existing bean definition files immediately.
>>	>
>>	>I've thought about this for a while, and I consider it very =
important to clarify the attributes in a way like the above. Else, it =
will be pretty hard to explain the rationale behind "bean" and =
"external", especially when using multiple XML files for a single =
context. "bean" and "bean-id" are far easier to explain: "bean" always =
works, "bean-id" adds validation by the XML parser if specifying a bean =
id in the same context.
>>	>
>>	>Any thoughts on this, any strong objections? I would actually like =
to get this into M2, although it's pretty close already. As the change =
is trivial to implement and fully backward compatible, that shouldn't =
matter too much.
>>	>=20
>>	>
>>	Even the current 'external' can be considered to still make sense if =
you
>>	ust consider it to mean the bean you are refering to is 'external' to
>>	the current xml file, as opposed to the current definition, that is =
it
>>	external to the current context.
>>=09
>>	However, I do agree that it's probably cleaner and makes more sense =
to
>>	just go with 'bean' and 'bean-id', and emphasize that the latter =
should
>>	be used if possible for extra validation... That point should =
definitely
>>	be documented properly (and used in the examples), so people don't
>>	accidentally throw away this free validation by using just 'bean'.
>>=09
>>




-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise=20
Linux in the Boardroom; in the Front Office; & in the Server Room=20
http://www.enterpriselinuxforum.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
                     +=12=17 ?[){([ ' +=1E.) Z+??`zw=1E Li8^=12Z+.) =
6??ig [ +kj?"8^=12{^?  b^=06?v(=17?9 q {ay' ?  0  +=1E) +o o             =
    *kx=1F  ?zZ)zXX*kx=1F? ?zZ)z l .a=1Ew i +-(=1E~ { b ?+-w k?x=1F? =
?zZ)

RE: [Springframework-developer] Petclinic Hibernate implementation

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

Thomas, Trevor,

> Does Hibernate use a different ID strategy for different databases?  I =
think
what is implemented in the Petclinic is a strategy that would work the =
same
across different databses as long as there is a MaxValueIncrementer =
implementation.

I intend to configure Hibernate to use "identity" for all databases. =
Setting the correct Hibernate dialect will lead to "auto_increment" on =
MySQL and "identity" on HSQL then. In terms of the data model, this =
simply means dropping the sequence tables and defining the id columns as =
"auto_increment" respectively "identity" in the DDL scripts.

Sure, MaxValueIncrementer adopts a very generic approach that will work =
on any database, even if it doesn't support such a thing like identity =
columns. The disadvantage is that the mechanism is normally not native =
to the database and thus somewhat tied to the application.

> If we change the Petclinic JDBC implementation to use identity =
columns, then we
need to figure out how to run the insert and subsequent query to =
retrieve the id
using the same connection whether we are in a transaction or not.

This is very similar with MySQL and HSQL: You simply run the insert =
without specifying a value for the id field, and query "select =
last_insert_id()" respectively "call identity()" afterwards (I've looked =
up the latter in Hibernate's MySQLDialect and HSQLDialect =
implementations). Petclinic already uses MySQLJdbcClinic and =
HSQLJdbcClinic subclasses; it should be easy to encapsulate the =
id-fetching query there.

Of course, the range of possible Petclinic JDBC implementations will =
then be bound to identity-supporting databases. According to the =
Hibernate docs, those are "DB2, MySQL, MS SQL Server, Sybase and =
HypersonicSQL". Oracle is notably absent; I think we can live with =
Petclinic not running on Oracle, if we can allow for a dynamic switch =
between JDBC and Hibernate on both MySQL and HSQL that way!

>>auto-increment just allows to read in the actual id afterwards
>This is not reliable for concurrent inserts (which is why I generally =
use sequences.  For the sample this should be sufficient though.

According to what I found out about MySQL, "last_insert_id" returns the =
last used id on the same connection and is thus transactionally safe. =
Don't know about HSQL, but I frankly don't mind for sample purposes.

Juergen

RE: [Springframework-developer] XML bean references

[Kopylenko, D. <dko...@ac...>]

+1 for 'local'

-----Original Message-----
From: j=C3=BCrgen h=C3=B6ller [werk3AT] =
[mailto:jue...@we...]=20
Sent: Monday, October 20, 2003 11:51 AM
To: spr...@li...
Subject: RE: [Springframework-developer] XML bean references


Colin,

Hmmm, you've got a point there. I also like "local" more; I just =
considered
"internal" as the opposite for "external". You're right that "external" =
will
probably not get used anymore; the only important different is =
referencing a
strictly local bean versus any bean.

I'm inclined to go the "bean" / "local" / "external"(deprecated) route
again... Votes please! Given this decision, I vote for "local" instead =
of
"internal"; Colin obviously does too.

Juergen


-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...]
Sent: Monday, October 20, 2003 4:50 PM
To: spr...@li...
Subject: Re: [Springframework-developer] XML bean references


I'm ok with this, although it's getting more verbose. I also wonder if=20
"external" would ever be used in the future at all? That is, would=20
somebody ever be interested in validating that something is only=20
external? Perhaps people would indeed use it due to the principal of=20
least surprise (that is, if you use only 'internal' and 'external', =
then=20
you always know exactly where your beans are coming from. But then why=20
use the 'ambiguous 'bean' at all?).

If you assume people would probably _not_ use 'external', then I think=20
your original 'local' is nicer name for bean id references that are=20
local to the file only.

i.e.:

- <ref bean=3D"..."/> can reference any bean by any name (equal to =
current
"external", similar to current "bean" but without XML idref check);
- <ref local=3D"..."/> can reference a bean id in the same XML file =
(equal to
the current "bean">
- <ref external=3D"..."/> deprecated, not enocuraged to be used, and
documented minimally.

If you _do_ think people would actually have a need for and use =
"external"
on an ongoing basis, then probably "internal" as the opposite does make =
more
sense than "local"...

Regards,

Colin


j=C3=BCrgen h=C3=B6ller [werk3AT] wrote:

>Third and hopefully final attempt at proper attribute naming, with=20
>"internal" instead of "local" (as it matches its counterpart =
"external"
better):
>
>- <ref bean=3D"..."/> can reference any bean by any name (equal to=20
>current "external", similar to current "bean" but without XML idref =
check);
>=20
>- <ref external=3D"..."/> stays as it is for the time being, but in =
its=20
>final incarnation, it should check that the reference is really =
outside the
current XML file;
>=20
>- <ref internal=3D"..."/> can reference a bean id in the same XML file =

>(equal to the formerly proposed "bean-id", with an XML idref check).
>
>Request for comments again :-)
>
>Juergen
>
>
>-----Original Message-----
>From: Colin Sampaleanu [mailto:col...@ex...]
>Sent: Monday, October 20, 2003 12:53 AM
>To: j=C3=BCrgen h=C3=B6ller [werk3AT]
>Cc: spr...@li...
>Subject: Re: [Springframework-developer] XML bean references
>
>
>I think this would work, and is probably the least ambiguous.
>
>j=C3=BCrgen h=C3=B6ller [werk3AT] wrote:
>
> =20
>
>>Colin, Rod,
>>
>>You're right regarding the term "external" for a different XML file,=20
>>not only a different context. On second thought, I consider "bean-id" =

>>unclear too, as beans in other XML files also have an "id". Thus, a=20
>>slightly refined suggestion:
>>
>>- <ref bean=3D"..."/> can reference any bean by any name (equal to=20
>>current "external", similar to current "bean" but without XML idref=20
>>check);
>>
>>- <ref external=3D"..."/> stays as it is for the time being, but in =
its=20
>>final incarnation, it should check that the reference is really=20
>>outside the current XML file;
>>
>>- <ref local=3D"..."/> can reference a bean id in the same XML file=20
>>(equal to the formerly proposed "bean-id", with an XML idref check).
>>
>>That's probably as easy to explain as possible: "bean" is the general =

>>one that can reference anything, "external" is for beans outside the=20
>>current file, "local" for beans inside the current file -- and it's=20
>>still backward-compatible. What do you think?
>>
>>Juergen
>>
>>
>>
>>	-----Urspr=C3=BCngliche Nachricht-----=20
>>	Von: Colin Sampaleanu [mailto:col...@ex...]=20
>>	Gesendet: So 19.10.2003 16:20=20
>>	An: j=C3=BCrgen h=C3=B6ller [werk3AT]=20
>>	Cc: spr...@li...=20
>>	Betreff: Re: [Springframework-developer] XML bean references
>>=09
>>=09
>>
>>	j=C3=BCrgen h=C3=B6ller [werk3AT] wrote:
>>=09
>>	>Everybody,
>>	>
>>	>On the occasion of allowing a single application context to be
loaded from multiple XML files, I've reconsidered a detail of our XML
syntax: The "ref" tag currently has two different attributes:
>>	>- "bean" to reference a bean in the same application context via
its id attribute (the XML id);
>>	>- "external" to reference a bean in a parent context.
>>	>The latter can basically address any bean, be it in the same
context or a parent, an id or an alias name.
>>	>
>>	>The main rationale behind the "bean"/"external" separation was
simply separating between XML validation of id refs (by the XML parser) =
and
referencing any kind of name (validated by the bean factory). The =
latter was
mainly necessary for referencing beans outside of the current XML file, =
at
that time a parent context. In the mean time, a single context can be
defined by multiple XML files; thus I don't consider the =
"bean"/"external"
naming appropriate anymore.
>>	>
>>	>Instead, let me suggest different attribute names:
>>	>- keep a "bean" attribute to reference *any* kind of name, be it id
or alias, just like the current "external" attribute;
>>	>- introduce a new "bean-id" attribute to reference a bean in the
same XML file via its XML id, like the current "bean" attribute.
>>	>
>>	>If we keep the "external" attribute for the moment as an equivalent
of the proposed "bean" attribute, this would be fully compatible with
existing bean definition files. Of course, "bean" attributes would not =
get
validated by the XML parser anymore, but that would not break the files =
in
any way. "external" attributes would still work too, the same as =
before.
>>	>
>>	>We should recommend migrating to the new pattern though, i.e.:
>>	>- rename "bean" to "bean-id";
>>	>- rename "external" to "bean".
>>	>That should be easy to do; and as the old pattern still works,
there is no need to migrate existing bean definition files immediately.
>>	>
>>	>I've thought about this for a while, and I consider it very
important to clarify the attributes in a way like the above. Else, it =
will
be pretty hard to explain the rationale behind "bean" and "external",
especially when using multiple XML files for a single context. "bean" =
and
"bean-id" are far easier to explain: "bean" always works, "bean-id" =
adds
validation by the XML parser if specifying a bean id in the same =
context.
>>	>
>>	>Any thoughts on this, any strong objections? I would actually like
to get this into M2, although it's pretty close already. As the change =
is
trivial to implement and fully backward compatible, that shouldn't =
matter
too much.
>>	>=20
>>	>
>>	Even the current 'external' can be considered to still make sense if
you
>>	ust consider it to mean the bean you are refering to is 'external'
to
>>	the current xml file, as opposed to the current definition, that is
it
>>	external to the current context.
>>=09
>>	However, I do agree that it's probably cleaner and makes more sense
to
>>	just go with 'bean' and 'bean-id', and emphasize that the latter
should
>>	be used if possible for extra validation... That point should
definitely
>>	be documented properly (and used in the examples), so people don't
>>	accidentally throw away this free validation by using just 'bean'.
>>=09
>>




-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & =
Expo The
Event For Linux Datacenter Solutions & Strategies in The Enterprise=20
Linux in the Boardroom; in the Front Office; & in the Server Room=20
http://www.enterpriselinuxforum.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
N=18HY=DE=B5=E9=9A=8A[){([oIzk=E1=AC=8A=C7=8B{=16*'}e=DE=9D=C7=84=C6=9A=13=
/z{E=E8=A2=B2=C5=BECj=D6=9Cz{^*%=D8=A8=C4=AD^'txInzk=C7=8B{{ax=1A=1A=1Ah=
=179mqe=17z=DE=AD=1A(=1Bm =CA=A7
+=1E)=0E+g(*kx=1F=E1=B6=AD=C5=A0ut=DE=96^f)+-J=E1=A1=9A =
ojg=1Dz=E5=A2=97+-.=E1=A6=AD=C7=9F=1Ea=E1=A1=B6lb,=E1=AC=A2
y+=E1=A1=81=DE=B7b=E0=A0=B2?+-w=08k=E1=A9=8Ax=1F=C5=A0ui=DE=96^

RE: [Springframework-developer] XML bean references

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

Q29saW4sDQoNCkhtbW0sIHlvdSd2ZSBnb3QgYSBwb2ludCB0aGVyZS4gSSBhbHNvIGxpa2UgImxv
Y2FsIiBtb3JlOyBJIGp1c3QgY29uc2lkZXJlZCAiaW50ZXJuYWwiIGFzIHRoZSBvcHBvc2l0ZSBm
b3IgImV4dGVybmFsIi4gWW91J3JlIHJpZ2h0IHRoYXQgImV4dGVybmFsIiB3aWxsIHByb2JhYmx5
IG5vdCBnZXQgdXNlZCBhbnltb3JlOyB0aGUgb25seSBpbXBvcnRhbnQgZGlmZmVyZW50IGlzIHJl
ZmVyZW5jaW5nIGEgc3RyaWN0bHkgbG9jYWwgYmVhbiB2ZXJzdXMgYW55IGJlYW4uDQoNCkknbSBp
bmNsaW5lZCB0byBnbyB0aGUgImJlYW4iIC8gImxvY2FsIiAvICJleHRlcm5hbCIoZGVwcmVjYXRl
ZCkgcm91dGUgYWdhaW4uLi4gVm90ZXMgcGxlYXNlISBHaXZlbiB0aGlzIGRlY2lzaW9uLCBJIHZv
dGUgZm9yICJsb2NhbCIgaW5zdGVhZCBvZiAiaW50ZXJuYWwiOyBDb2xpbiBvYnZpb3VzbHkgZG9l
cyB0b28uDQoNCkp1ZXJnZW4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog
Q29saW4gU2FtcGFsZWFudSBbbWFpbHRvOmNvbGlubWwxQGV4aXMuY29tXQ0KU2VudDogTW9uZGF5
LCBPY3RvYmVyIDIwLCAyMDAzIDQ6NTAgUE0NClRvOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVy
QGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KU3ViamVjdDogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2
ZWxvcGVyXSBYTUwgYmVhbiByZWZlcmVuY2VzDQoNCg0KSSdtIG9rIHdpdGggdGhpcywgYWx0aG91
Z2ggaXQncyBnZXR0aW5nIG1vcmUgdmVyYm9zZS4gSSBhbHNvIHdvbmRlciBpZiANCiJleHRlcm5h
bCIgd291bGQgZXZlciBiZSB1c2VkIGluIHRoZSBmdXR1cmUgYXQgYWxsPyBUaGF0IGlzLCB3b3Vs
ZCANCnNvbWVib2R5IGV2ZXIgYmUgaW50ZXJlc3RlZCBpbiB2YWxpZGF0aW5nIHRoYXQgc29tZXRo
aW5nIGlzIG9ubHkgDQpleHRlcm5hbD8gUGVyaGFwcyBwZW9wbGUgd291bGQgaW5kZWVkIHVzZSBp
dCBkdWUgdG8gdGhlIHByaW5jaXBhbCBvZiANCmxlYXN0IHN1cnByaXNlICh0aGF0IGlzLCBpZiB5
b3UgdXNlIG9ubHkgJ2ludGVybmFsJyBhbmQgJ2V4dGVybmFsJywgdGhlbiANCnlvdSBhbHdheXMg
a25vdyBleGFjdGx5IHdoZXJlIHlvdXIgYmVhbnMgYXJlIGNvbWluZyBmcm9tLiBCdXQgdGhlbiB3
aHkgDQp1c2UgdGhlICdhbWJpZ3VvdXMgJ2JlYW4nIGF0IGFsbD8pLg0KDQpJZiB5b3UgYXNzdW1l
IHBlb3BsZSB3b3VsZCBwcm9iYWJseSBfbm90XyB1c2UgJ2V4dGVybmFsJywgdGhlbiBJIHRoaW5r
IA0KeW91ciBvcmlnaW5hbCAnbG9jYWwnIGlzIG5pY2VyIG5hbWUgZm9yIGJlYW4gaWQgcmVmZXJl
bmNlcyB0aGF0IGFyZSANCmxvY2FsIHRvIHRoZSBmaWxlIG9ubHkuDQoNCmkuZS46DQoNCi0gPHJl
ZiBiZWFuPSIuLi4iLz4gY2FuIHJlZmVyZW5jZSBhbnkgYmVhbiBieSBhbnkgbmFtZSAoZXF1YWwg
dG8gY3VycmVudCAiZXh0ZXJuYWwiLCBzaW1pbGFyIHRvIGN1cnJlbnQgImJlYW4iIGJ1dCB3aXRo
b3V0IFhNTCBpZHJlZiBjaGVjayk7DQotIDxyZWYgbG9jYWw9Ii4uLiIvPiBjYW4gcmVmZXJlbmNl
IGEgYmVhbiBpZCBpbiB0aGUgc2FtZSBYTUwgZmlsZSAoZXF1YWwgdG8gdGhlIGN1cnJlbnQgImJl
YW4iPg0KLSA8cmVmIGV4dGVybmFsPSIuLi4iLz4gZGVwcmVjYXRlZCwgbm90IGVub2N1cmFnZWQg
dG8gYmUgdXNlZCwgYW5kIGRvY3VtZW50ZWQgbWluaW1hbGx5Lg0KDQpJZiB5b3UgX2RvXyB0aGlu
ayBwZW9wbGUgd291bGQgYWN0dWFsbHkgaGF2ZSBhIG5lZWQgZm9yIGFuZCB1c2UgImV4dGVybmFs
IiBvbiBhbiBvbmdvaW5nIGJhc2lzLCB0aGVuIHByb2JhYmx5ICJpbnRlcm5hbCIgYXMgdGhlIG9w
cG9zaXRlIGRvZXMgbWFrZSBtb3JlIHNlbnNlIHRoYW4gImxvY2FsIi4uLg0KDQpSZWdhcmRzLA0K
DQpDb2xpbg0KDQoNCmrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF0gd3JvdGU6DQoNCj5UaGlyZCBh
bmQgaG9wZWZ1bGx5IGZpbmFsIGF0dGVtcHQgYXQgcHJvcGVyIGF0dHJpYnV0ZSBuYW1pbmcsIHdp
dGggImludGVybmFsIiBpbnN0ZWFkIG9mICJsb2NhbCIgKGFzIGl0IG1hdGNoZXMgaXRzIGNvdW50
ZXJwYXJ0ICJleHRlcm5hbCIgYmV0dGVyKTogDQo+DQo+LSA8cmVmIGJlYW49Ii4uLiIvPiBjYW4g
cmVmZXJlbmNlIGFueSBiZWFuIGJ5IGFueSBuYW1lIChlcXVhbCB0byBjdXJyZW50ICJleHRlcm5h
bCIsIHNpbWlsYXIgdG8gY3VycmVudCAiYmVhbiIgYnV0IHdpdGhvdXQgWE1MIGlkcmVmIGNoZWNr
KTsNCj4gDQo+LSA8cmVmIGV4dGVybmFsPSIuLi4iLz4gc3RheXMgYXMgaXQgaXMgZm9yIHRoZSB0
aW1lIGJlaW5nLCBidXQgaW4gaXRzIGZpbmFsIGluY2FybmF0aW9uLCBpdCBzaG91bGQgY2hlY2sg
dGhhdCB0aGUgcmVmZXJlbmNlIGlzIHJlYWxseSBvdXRzaWRlIHRoZSBjdXJyZW50IFhNTCBmaWxl
Ow0KPiANCj4tIDxyZWYgaW50ZXJuYWw9Ii4uLiIvPiBjYW4gcmVmZXJlbmNlIGEgYmVhbiBpZCBp
biB0aGUgc2FtZSBYTUwgZmlsZSAoZXF1YWwgdG8gdGhlIGZvcm1lcmx5IHByb3Bvc2VkICJiZWFu
LWlkIiwgd2l0aCBhbiBYTUwgaWRyZWYgY2hlY2spLg0KPg0KPlJlcXVlc3QgZm9yIGNvbW1lbnRz
IGFnYWluIDotKQ0KPg0KPkp1ZXJnZW4NCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPkZyb206IENvbGluIFNhbXBhbGVhbnUgW21haWx0bzpjb2xpbm1sMUBleGlzLmNvbV0NCj5T
ZW50OiBNb25kYXksIE9jdG9iZXIgMjAsIDIwMDMgMTI6NTMgQU0NCj5UbzogasO8cmdlbiBow7Zs
bGVyIFt3ZXJrM0FUXQ0KPkNjOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJj
ZWZvcmdlLm5ldA0KPlN1YmplY3Q6IFJlOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gWE1M
IGJlYW4gcmVmZXJlbmNlcw0KPg0KPg0KPkkgdGhpbmsgdGhpcyB3b3VsZCB3b3JrLCBhbmQgaXMg
cHJvYmFibHkgdGhlIGxlYXN0IGFtYmlndW91cy4NCj4NCj5qw7xyZ2VuIGjDtmxsZXIgW3dlcmsz
QVRdIHdyb3RlOg0KPg0KPiAgDQo+DQo+PkNvbGluLCBSb2QsDQo+Pg0KPj5Zb3UncmUgcmlnaHQg
cmVnYXJkaW5nIHRoZSB0ZXJtICJleHRlcm5hbCIgZm9yIGEgZGlmZmVyZW50IFhNTCBmaWxlLCBu
b3Qgb25seSBhIGRpZmZlcmVudCBjb250ZXh0LiBPbiBzZWNvbmQgdGhvdWdodCwgSSBjb25zaWRl
ciAiYmVhbi1pZCIgdW5jbGVhciB0b28sIGFzIGJlYW5zIGluIG90aGVyIFhNTCBmaWxlcyBhbHNv
IGhhdmUgYW4gImlkIi4gVGh1cywgYSBzbGlnaHRseSByZWZpbmVkIHN1Z2dlc3Rpb246DQo+Pg0K
Pj4tIDxyZWYgYmVhbj0iLi4uIi8+IGNhbiByZWZlcmVuY2UgYW55IGJlYW4gYnkgYW55IG5hbWUg
KGVxdWFsIHRvIGN1cnJlbnQgImV4dGVybmFsIiwgc2ltaWxhciB0byBjdXJyZW50ICJiZWFuIiBi
dXQgd2l0aG91dCBYTUwgaWRyZWYgY2hlY2spOw0KPj4NCj4+LSA8cmVmIGV4dGVybmFsPSIuLi4i
Lz4gc3RheXMgYXMgaXQgaXMgZm9yIHRoZSB0aW1lIGJlaW5nLCBidXQgaW4gaXRzIGZpbmFsIGlu
Y2FybmF0aW9uLCBpdCBzaG91bGQgY2hlY2sgdGhhdCB0aGUgcmVmZXJlbmNlIGlzIHJlYWxseSBv
dXRzaWRlIHRoZSBjdXJyZW50IFhNTCBmaWxlOw0KPj4NCj4+LSA8cmVmIGxvY2FsPSIuLi4iLz4g
Y2FuIHJlZmVyZW5jZSBhIGJlYW4gaWQgaW4gdGhlIHNhbWUgWE1MIGZpbGUgKGVxdWFsIHRvIHRo
ZSBmb3JtZXJseSBwcm9wb3NlZCAiYmVhbi1pZCIsIHdpdGggYW4gWE1MIGlkcmVmIGNoZWNrKS4N
Cj4+DQo+PlRoYXQncyBwcm9iYWJseSBhcyBlYXN5IHRvIGV4cGxhaW4gYXMgcG9zc2libGU6ICJi
ZWFuIiBpcyB0aGUgZ2VuZXJhbCBvbmUgdGhhdCBjYW4gcmVmZXJlbmNlIGFueXRoaW5nLCAiZXh0
ZXJuYWwiIGlzIGZvciBiZWFucyBvdXRzaWRlIHRoZSBjdXJyZW50IGZpbGUsICJsb2NhbCIgZm9y
IGJlYW5zIGluc2lkZSB0aGUgY3VycmVudCBmaWxlIC0tIGFuZCBpdCdzIHN0aWxsIGJhY2t3YXJk
LWNvbXBhdGlibGUuIFdoYXQgZG8geW91IHRoaW5rPw0KPj4NCj4+SnVlcmdlbg0KPj4NCj4+DQo+
Pg0KPj4JLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCj4+CVZvbjogQ29saW4g
U2FtcGFsZWFudSBbbWFpbHRvOmNvbGlubWwxQGV4aXMuY29tXSANCj4+CUdlc2VuZGV0OiBTbyAx
OS4xMC4yMDAzIDE2OjIwIA0KPj4JQW46IGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF0gDQo+PglD
Yzogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQo+PglC
ZXRyZWZmOiBSZTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIFhNTCBiZWFuIHJlZmVyZW5j
ZXMNCj4+CQ0KPj4JDQo+Pg0KPj4JasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXSB3cm90ZToNCj4+
CQ0KPj4JPkV2ZXJ5Ym9keSwNCj4+CT4NCj4+CT5PbiB0aGUgb2NjYXNpb24gb2YgYWxsb3dpbmcg
YSBzaW5nbGUgYXBwbGljYXRpb24gY29udGV4dCB0byBiZSBsb2FkZWQgZnJvbSBtdWx0aXBsZSBY
TUwgZmlsZXMsIEkndmUgcmVjb25zaWRlcmVkIGEgZGV0YWlsIG9mIG91ciBYTUwgc3ludGF4OiBU
aGUgInJlZiIgdGFnIGN1cnJlbnRseSBoYXMgdHdvIGRpZmZlcmVudCBhdHRyaWJ1dGVzOg0KPj4J
Pi0gImJlYW4iIHRvIHJlZmVyZW5jZSBhIGJlYW4gaW4gdGhlIHNhbWUgYXBwbGljYXRpb24gY29u
dGV4dCB2aWEgaXRzIGlkIGF0dHJpYnV0ZSAodGhlIFhNTCBpZCk7DQo+Pgk+LSAiZXh0ZXJuYWwi
IHRvIHJlZmVyZW5jZSBhIGJlYW4gaW4gYSBwYXJlbnQgY29udGV4dC4NCj4+CT5UaGUgbGF0dGVy
IGNhbiBiYXNpY2FsbHkgYWRkcmVzcyBhbnkgYmVhbiwgYmUgaXQgaW4gdGhlIHNhbWUgY29udGV4
dCBvciBhIHBhcmVudCwgYW4gaWQgb3IgYW4gYWxpYXMgbmFtZS4NCj4+CT4NCj4+CT5UaGUgbWFp
biByYXRpb25hbGUgYmVoaW5kIHRoZSAiYmVhbiIvImV4dGVybmFsIiBzZXBhcmF0aW9uIHdhcyBz
aW1wbHkgc2VwYXJhdGluZyBiZXR3ZWVuIFhNTCB2YWxpZGF0aW9uIG9mIGlkIHJlZnMgKGJ5IHRo
ZSBYTUwgcGFyc2VyKSBhbmQgcmVmZXJlbmNpbmcgYW55IGtpbmQgb2YgbmFtZSAodmFsaWRhdGVk
IGJ5IHRoZSBiZWFuIGZhY3RvcnkpLiBUaGUgbGF0dGVyIHdhcyBtYWlubHkgbmVjZXNzYXJ5IGZv
ciByZWZlcmVuY2luZyBiZWFucyBvdXRzaWRlIG9mIHRoZSBjdXJyZW50IFhNTCBmaWxlLCBhdCB0
aGF0IHRpbWUgYSBwYXJlbnQgY29udGV4dC4gSW4gdGhlIG1lYW4gdGltZSwgYSBzaW5nbGUgY29u
dGV4dCBjYW4gYmUgZGVmaW5lZCBieSBtdWx0aXBsZSBYTUwgZmlsZXM7IHRodXMgSSBkb24ndCBj
b25zaWRlciB0aGUgImJlYW4iLyJleHRlcm5hbCIgbmFtaW5nIGFwcHJvcHJpYXRlIGFueW1vcmUu
DQo+Pgk+DQo+Pgk+SW5zdGVhZCwgbGV0IG1lIHN1Z2dlc3QgZGlmZmVyZW50IGF0dHJpYnV0ZSBu
YW1lczoNCj4+CT4tIGtlZXAgYSAiYmVhbiIgYXR0cmlidXRlIHRvIHJlZmVyZW5jZSAqYW55KiBr
aW5kIG9mIG5hbWUsIGJlIGl0IGlkIG9yIGFsaWFzLCBqdXN0IGxpa2UgdGhlIGN1cnJlbnQgImV4
dGVybmFsIiBhdHRyaWJ1dGU7DQo+Pgk+LSBpbnRyb2R1Y2UgYSBuZXcgImJlYW4taWQiIGF0dHJp
YnV0ZSB0byByZWZlcmVuY2UgYSBiZWFuIGluIHRoZSBzYW1lIFhNTCBmaWxlIHZpYSBpdHMgWE1M
IGlkLCBsaWtlIHRoZSBjdXJyZW50ICJiZWFuIiBhdHRyaWJ1dGUuDQo+Pgk+DQo+Pgk+SWYgd2Ug
a2VlcCB0aGUgImV4dGVybmFsIiBhdHRyaWJ1dGUgZm9yIHRoZSBtb21lbnQgYXMgYW4gZXF1aXZh
bGVudCBvZiB0aGUgcHJvcG9zZWQgImJlYW4iIGF0dHJpYnV0ZSwgdGhpcyB3b3VsZCBiZSBmdWxs
eSBjb21wYXRpYmxlIHdpdGggZXhpc3RpbmcgYmVhbiBkZWZpbml0aW9uIGZpbGVzLiBPZiBjb3Vy
c2UsICJiZWFuIiBhdHRyaWJ1dGVzIHdvdWxkIG5vdCBnZXQgdmFsaWRhdGVkIGJ5IHRoZSBYTUwg
cGFyc2VyIGFueW1vcmUsIGJ1dCB0aGF0IHdvdWxkIG5vdCBicmVhayB0aGUgZmlsZXMgaW4gYW55
IHdheS4gImV4dGVybmFsIiBhdHRyaWJ1dGVzIHdvdWxkIHN0aWxsIHdvcmsgdG9vLCB0aGUgc2Ft
ZSBhcyBiZWZvcmUuDQo+Pgk+DQo+Pgk+V2Ugc2hvdWxkIHJlY29tbWVuZCBtaWdyYXRpbmcgdG8g
dGhlIG5ldyBwYXR0ZXJuIHRob3VnaCwgaS5lLjoNCj4+CT4tIHJlbmFtZSAiYmVhbiIgdG8gImJl
YW4taWQiOw0KPj4JPi0gcmVuYW1lICJleHRlcm5hbCIgdG8gImJlYW4iLg0KPj4JPlRoYXQgc2hv
dWxkIGJlIGVhc3kgdG8gZG87IGFuZCBhcyB0aGUgb2xkIHBhdHRlcm4gc3RpbGwgd29ya3MsIHRo
ZXJlIGlzIG5vIG5lZWQgdG8gbWlncmF0ZSBleGlzdGluZyBiZWFuIGRlZmluaXRpb24gZmlsZXMg
aW1tZWRpYXRlbHkuDQo+Pgk+DQo+Pgk+SSd2ZSB0aG91Z2h0IGFib3V0IHRoaXMgZm9yIGEgd2hp
bGUsIGFuZCBJIGNvbnNpZGVyIGl0IHZlcnkgaW1wb3J0YW50IHRvIGNsYXJpZnkgdGhlIGF0dHJp
YnV0ZXMgaW4gYSB3YXkgbGlrZSB0aGUgYWJvdmUuIEVsc2UsIGl0IHdpbGwgYmUgcHJldHR5IGhh
cmQgdG8gZXhwbGFpbiB0aGUgcmF0aW9uYWxlIGJlaGluZCAiYmVhbiIgYW5kICJleHRlcm5hbCIs
IGVzcGVjaWFsbHkgd2hlbiB1c2luZyBtdWx0aXBsZSBYTUwgZmlsZXMgZm9yIGEgc2luZ2xlIGNv
bnRleHQuICJiZWFuIiBhbmQgImJlYW4taWQiIGFyZSBmYXIgZWFzaWVyIHRvIGV4cGxhaW46ICJi
ZWFuIiBhbHdheXMgd29ya3MsICJiZWFuLWlkIiBhZGRzIHZhbGlkYXRpb24gYnkgdGhlIFhNTCBw
YXJzZXIgaWYgc3BlY2lmeWluZyBhIGJlYW4gaWQgaW4gdGhlIHNhbWUgY29udGV4dC4NCj4+CT4N
Cj4+CT5BbnkgdGhvdWdodHMgb24gdGhpcywgYW55IHN0cm9uZyBvYmplY3Rpb25zPyBJIHdvdWxk
IGFjdHVhbGx5IGxpa2UgdG8gZ2V0IHRoaXMgaW50byBNMiwgYWx0aG91Z2ggaXQncyBwcmV0dHkg
Y2xvc2UgYWxyZWFkeS4gQXMgdGhlIGNoYW5nZSBpcyB0cml2aWFsIHRvIGltcGxlbWVudCBhbmQg
ZnVsbHkgYmFja3dhcmQgY29tcGF0aWJsZSwgdGhhdCBzaG91bGRuJ3QgbWF0dGVyIHRvbyBtdWNo
Lg0KPj4JPiANCj4+CT4NCj4+CUV2ZW4gdGhlIGN1cnJlbnQgJ2V4dGVybmFsJyBjYW4gYmUgY29u
c2lkZXJlZCB0byBzdGlsbCBtYWtlIHNlbnNlIGlmIHlvdQ0KPj4JdXN0IGNvbnNpZGVyIGl0IHRv
IG1lYW4gdGhlIGJlYW4geW91IGFyZSByZWZlcmluZyB0byBpcyAnZXh0ZXJuYWwnIHRvDQo+Pgl0
aGUgY3VycmVudCB4bWwgZmlsZSwgYXMgb3Bwb3NlZCB0byB0aGUgY3VycmVudCBkZWZpbml0aW9u
LCB0aGF0IGlzIGl0DQo+PglleHRlcm5hbCB0byB0aGUgY3VycmVudCBjb250ZXh0Lg0KPj4JDQo+
PglIb3dldmVyLCBJIGRvIGFncmVlIHRoYXQgaXQncyBwcm9iYWJseSBjbGVhbmVyIGFuZCBtYWtl
cyBtb3JlIHNlbnNlIHRvDQo+PglqdXN0IGdvIHdpdGggJ2JlYW4nIGFuZCAnYmVhbi1pZCcsIGFu
ZCBlbXBoYXNpemUgdGhhdCB0aGUgbGF0dGVyIHNob3VsZA0KPj4JYmUgdXNlZCBpZiBwb3NzaWJs
ZSBmb3IgZXh0cmEgdmFsaWRhdGlvbi4uLiBUaGF0IHBvaW50IHNob3VsZCBkZWZpbml0ZWx5DQo+
PgliZSBkb2N1bWVudGVkIHByb3Blcmx5IChhbmQgdXNlZCBpbiB0aGUgZXhhbXBsZXMpLCBzbyBw
ZW9wbGUgZG9uJ3QNCj4+CWFjY2lkZW50YWxseSB0aHJvdyBhd2F5IHRoaXMgZnJlZSB2YWxpZGF0
aW9uIGJ5IHVzaW5nIGp1c3QgJ2JlYW4nLg0KPj4JDQo+Pg0KDQoNCg0KDQotLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIFNGLm5ldCBl
bWFpbCBzcG9uc29yZWQgYnk6IEVudGVycHJpc2UgTGludXggRm9ydW0gQ29uZmVyZW5jZSAmIEV4
cG8NClRoZSBFdmVudCBGb3IgTGludXggRGF0YWNlbnRlciBTb2x1dGlvbnMgJiBTdHJhdGVnaWVz
IGluIFRoZSBFbnRlcnByaXNlIA0KTGludXggaW4gdGhlIEJvYXJkcm9vbTsgaW4gdGhlIEZyb250
IE9mZmljZTsgJiBpbiB0aGUgU2VydmVyIFJvb20gDQpodHRwOi8vd3d3LmVudGVycHJpc2VsaW51
eGZvcnVtLmNvbQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NClNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQpTcHJpbmdmcmFtZXdv
cmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KaHR0cHM6Ly9saXN0cy5zb3VyY2Vm
b3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcg0K

Re: [Springframework-developer] Petclinic Hibernate implementation

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

Interesting, so in the case of sequences (Oracle sequences, in any 
case), Hibernate's save (or saveOrUpdate) will go and read the next 
sequence value from the db, so it can assign the id, but will not 
actually write the row until the flush. In the case of identity columns, 
it does an actual write immediately (as per your comment below), which 
makes sense, as it's the only way it can actually get the id value to 
assign to the objects as part of the save or saveOrUpdate.

This all has interesting implications in a few respects, including 
performance. Basically, I think user or Hibernate assigned IDs (such as 
GUIDs) would perform best, since the db is not hit until the actual 
entity write, followed by a seqhilo (hilo which uses a sequence for one 
half the value), followed by a hilo, then sequences, then identity.



jürgen höller [werk3AT] wrote:

>Colin, Trevor,
> 
>Session.save immediately inserts the object to the database, therefore it is able to set id into the object in any case. AFAIK, Session.update just inserts the object into the Session's object cache, to be flushed in the normal way. So Session.save seems to receive special treatment.
> 
>  
>
>>>auto-increment just allows to read in the actual id afterwards
>>>      
>>>
>>This is not reliable for concurrent inserts (which is why I generally use sequences.  For the sample this should be sufficient though.
>>    
>>
> 
>This is not reliable even with proper transactions? Shouldn't "last_insert_id" or whatever it is called return the last inserted id in the same transaction, allowing for concurrent inserts in different transactions?
> 
>Basically, the change for the sample would be straightforward: Drop all the manually handled sequence tables and turn the id columns into identity columns. This would allow for using Hibernate's out-of-the-box "identity" strategy; the JDBC implementation would have to do manual "last_insert_id" queries after the actual domain inserts.
> 
>Juergen
> 
>
>	-----Ursprüngliche Nachricht----- 
>	Von: Colin Sampaleanu [mailto:col...@ex...] 
>	Gesendet: Mo 20.10.2003 05:27 
>	An: spr...@li... 
>	Cc: 
>	Betreff: Re: [Springframework-developer] Petclinic Hibernate implementation
>	
>	
>
>	jürgen höller [werk3AT] wrote:
>	
>	>Hi everybody,
>	>
>	>...
>	>
>	>BTW, we are using auto-increment for all MySQL databases at werk3AT, and it works nicely. I'd really like to understand the rationale for manual sequence handling. The only one I see is that the id can be determined before the domain insert/update statement this way, while auto-increment just allows to read in the actual id afterwards. But does that really matter for Petclinic? Wouldn't it be easier to use auto-increment/identity on both MySQL and HSQL?
>	>
>	> 
>	>
>	Only somewhat related, but how does the auto-increment get handled
>	w/regards to Hibernate's 'save' function? That is, with an Oracle
>	sequence or some of the other (hi/lo, etc.) strategies, when you call
>	Hibernate's save function, your objects will get proper ids, even though
>	they don't get written to the db until they actually get flushed. This
>	is because the db has already been hit for the Oracle sequence or for
>	the manual sequence table column.
>	
>	What happens in your case with MySQL's auto-increment columns
>	(essentially similar to SQL Server's identity columns). Do the IDs stay
>	null (or whatever the unsaved value is) until Hibernate's flush actually
>	gets called?
>	 Just curious since I've never used either MySQL or SQL Server with
>	Hibernate...
>	
>	Colin
>	
>	
>

Re: [Springframework-developer] XML bean references

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

I'm ok with this, although it's getting more verbose. I also wonder if 
"external" would ever be used in the future at all? That is, would 
somebody ever be interested in validating that something is only 
external? Perhaps people would indeed use it due to the principal of 
least surprise (that is, if you use only 'internal' and 'external', then 
you always know exactly where your beans are coming from. But then why 
use the 'ambiguous 'bean' at all?).

If you assume people would probably _not_ use 'external', then I think 
your original 'local' is nicer name for bean id references that are 
local to the file only.

i.e.:

- <ref bean="..."/> can reference any bean by any name (equal to current "external", similar to current "bean" but without XML idref check);
- <ref local="..."/> can reference a bean id in the same XML file (equal to the current "bean">
- <ref external="..."/> deprecated, not enocuraged to be used, and documented minimally.

If you _do_ think people would actually have a need for and use "external" on an ongoing basis, then probably "internal" as the opposite does make more sense than "local"...

Regards,

Colin


jürgen höller [werk3AT] wrote:

>Third and hopefully final attempt at proper attribute naming, with "internal" instead of "local" (as it matches its counterpart "external" better): 
>
>- <ref bean="..."/> can reference any bean by any name (equal to current "external", similar to current "bean" but without XML idref check);
> 
>- <ref external="..."/> stays as it is for the time being, but in its final incarnation, it should check that the reference is really outside the current XML file;
> 
>- <ref internal="..."/> can reference a bean id in the same XML file (equal to the formerly proposed "bean-id", with an XML idref check).
>
>Request for comments again :-)
>
>Juergen
>
>
>-----Original Message-----
>From: Colin Sampaleanu [mailto:col...@ex...]
>Sent: Monday, October 20, 2003 12:53 AM
>To: jürgen höller [werk3AT]
>Cc: spr...@li...
>Subject: Re: [Springframework-developer] XML bean references
>
>
>I think this would work, and is probably the least ambiguous.
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Colin, Rod,
>>
>>You're right regarding the term "external" for a different XML file, not only a different context. On second thought, I consider "bean-id" unclear too, as beans in other XML files also have an "id". Thus, a slightly refined suggestion:
>>
>>- <ref bean="..."/> can reference any bean by any name (equal to current "external", similar to current "bean" but without XML idref check);
>>
>>- <ref external="..."/> stays as it is for the time being, but in its final incarnation, it should check that the reference is really outside the current XML file;
>>
>>- <ref local="..."/> can reference a bean id in the same XML file (equal to the formerly proposed "bean-id", with an XML idref check).
>>
>>That's probably as easy to explain as possible: "bean" is the general one that can reference anything, "external" is for beans outside the current file, "local" for beans inside the current file -- and it's still backward-compatible. What do you think?
>>
>>Juergen
>>
>>
>>
>>	-----Ursprüngliche Nachricht----- 
>>	Von: Colin Sampaleanu [mailto:col...@ex...] 
>>	Gesendet: So 19.10.2003 16:20 
>>	An: jürgen höller [werk3AT] 
>>	Cc: spr...@li... 
>>	Betreff: Re: [Springframework-developer] XML bean references
>>	
>>	
>>
>>	jürgen höller [werk3AT] wrote:
>>	
>>	>Everybody,
>>	>
>>	>On the occasion of allowing a single application context to be loaded from multiple XML files, I've reconsidered a detail of our XML syntax: The "ref" tag currently has two different attributes:
>>	>- "bean" to reference a bean in the same application context via its id attribute (the XML id);
>>	>- "external" to reference a bean in a parent context.
>>	>The latter can basically address any bean, be it in the same context or a parent, an id or an alias name.
>>	>
>>	>The main rationale behind the "bean"/"external" separation was simply separating between XML validation of id refs (by the XML parser) and referencing any kind of name (validated by the bean factory). The latter was mainly necessary for referencing beans outside of the current XML file, at that time a parent context. In the mean time, a single context can be defined by multiple XML files; thus I don't consider the "bean"/"external" naming appropriate anymore.
>>	>
>>	>Instead, let me suggest different attribute names:
>>	>- keep a "bean" attribute to reference *any* kind of name, be it id or alias, just like the current "external" attribute;
>>	>- introduce a new "bean-id" attribute to reference a bean in the same XML file via its XML id, like the current "bean" attribute.
>>	>
>>	>If we keep the "external" attribute for the moment as an equivalent of the proposed "bean" attribute, this would be fully compatible with existing bean definition files. Of course, "bean" attributes would not get validated by the XML parser anymore, but that would not break the files in any way. "external" attributes would still work too, the same as before.
>>	>
>>	>We should recommend migrating to the new pattern though, i.e.:
>>	>- rename "bean" to "bean-id";
>>	>- rename "external" to "bean".
>>	>That should be easy to do; and as the old pattern still works, there is no need to migrate existing bean definition files immediately.
>>	>
>>	>I've thought about this for a while, and I consider it very important to clarify the attributes in a way like the above. Else, it will be pretty hard to explain the rationale behind "bean" and "external", especially when using multiple XML files for a single context. "bean" and "bean-id" are far easier to explain: "bean" always works, "bean-id" adds validation by the XML parser if specifying a bean id in the same context.
>>	>
>>	>Any thoughts on this, any strong objections? I would actually like to get this into M2, although it's pretty close already. As the change is trivial to implement and fully backward compatible, that shouldn't matter too much.
>>	> 
>>	>
>>	Even the current 'external' can be considered to still make sense if you
>>	ust consider it to mean the bean you are refering to is 'external' to
>>	the current xml file, as opposed to the current definition, that is it
>>	external to the current context.
>>	
>>	However, I do agree that it's probably cleaner and makes more sense to
>>	just go with 'bean' and 'bean-id', and emphasize that the latter should
>>	be used if possible for extra validation... That point should definitely
>>	be documented properly (and used in the examples), so people don't
>>	accidentally throw away this free validation by using just 'bean'.
>>	
>>

Re: [Springframework-developer] Petclinic Hibernate implementation

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

tri...@tr... wrote:

>Juergen,
>
>
>  
>
>>Generally, everything works nicely so far on both implementations. There's
>>one issue though: HsqlJdbcClinic uses HsqlMaxValueIncrementer for id
>>generation, with one sequence table per domain table. Hibernate doesn't have
>>a similar id generation strategy, so I'm wondering what to do to make both
>>impls work on the same database. The Hibernate docs say that HSQL supports
>>"identity" for id columns; why are we not using this for HsqlJdbcClinic too?
>>I.e. making the id columns identity columns and getting rid of all the
>>sequence tables. I guess there's a drawback with this; can anyone shed some
>>light on the issue?
>> 
>>    
>>
>
>Does Hibernate use a different ID strategy for different databases?  I think
>what is implemented in the Petclinic is a strategy that would work the same
>across different databses as long as there is a MaxValueIncrementer implementation.
>
>If we change the Petclinic JDBC implementation to use identity columns, then we
>need to figure out how to run the insert and subsequent query to retrieve the id
>using the same connection whether we are in a transaction or not.
>
>Thomas
>
>  
>
Hibernate has an id strategy called 'native', where it then actually 
uses identity, sequence, or hilo strategies for generating the id, 
depending on the db you are talking to.  This works pretty well as long 
as you don't care about the exact format of your ids.

Re: [Springframework-developer] MVC-step-by-step test suite

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

Juergen,

Yes, I have updated the tutorial and it is in CVS.  I also switched the
references to the download files from m1 to m2, so it is ready for our next release.

Thomas

> Thomas,
>  
> Have you reworked the MVC-step-by-step tutorial regarding the test suite?
> There has been the issue with the web frameworks objects now requiring a
> WebApplicationContext due to the 1.0-M1-introduced
> WebApplicationObjectSupport. I've been the one that introduced that,
> unfortunately being unaware of the side effect on the tutorial; I still
> consider it more correct to require a WebApplicationContext though. There is
> still a bug entry on this at SourceForge; has this been resolved now?
>  
> Juergen
> 

Re: [Springframework-developer] Petclinic Hibernate implementation

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

Juergen,


> Generally, everything works nicely so far on both implementations. There's
> one issue though: HsqlJdbcClinic uses HsqlMaxValueIncrementer for id
> generation, with one sequence table per domain table. Hibernate doesn't have
> a similar id generation strategy, so I'm wondering what to do to make both
> impls work on the same database. The Hibernate docs say that HSQL supports
> "identity" for id columns; why are we not using this for HsqlJdbcClinic too?
> I.e. making the id columns identity columns and getting rid of all the
> sequence tables. I guess there's a drawback with this; can anyone shed some
> light on the issue?
>  

Does Hibernate use a different ID strategy for different databases?  I think
what is implemented in the Petclinic is a strategy that would work the same
across different databses as long as there is a MaxValueIncrementer implementation.

If we change the Petclinic JDBC implementation to use identity columns, then we
need to figure out how to run the insert and subsequent query to retrieve the id
using the same connection whether we are in a transaction or not.

Thomas

RE: [Springframework-developer] XML bean references

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

VGhpcmQgYW5kIGhvcGVmdWxseSBmaW5hbCBhdHRlbXB0IGF0IHByb3BlciBhdHRyaWJ1dGUgbmFt
aW5nLCB3aXRoICJpbnRlcm5hbCIgaW5zdGVhZCBvZiAibG9jYWwiIChhcyBpdCBtYXRjaGVzIGl0
cyBjb3VudGVycGFydCAiZXh0ZXJuYWwiIGJldHRlcik6IA0KDQotIDxyZWYgYmVhbj0iLi4uIi8+
IGNhbiByZWZlcmVuY2UgYW55IGJlYW4gYnkgYW55IG5hbWUgKGVxdWFsIHRvIGN1cnJlbnQgImV4
dGVybmFsIiwgc2ltaWxhciB0byBjdXJyZW50ICJiZWFuIiBidXQgd2l0aG91dCBYTUwgaWRyZWYg
Y2hlY2spOw0KIA0KLSA8cmVmIGV4dGVybmFsPSIuLi4iLz4gc3RheXMgYXMgaXQgaXMgZm9yIHRo
ZSB0aW1lIGJlaW5nLCBidXQgaW4gaXRzIGZpbmFsIGluY2FybmF0aW9uLCBpdCBzaG91bGQgY2hl
Y2sgdGhhdCB0aGUgcmVmZXJlbmNlIGlzIHJlYWxseSBvdXRzaWRlIHRoZSBjdXJyZW50IFhNTCBm
aWxlOw0KIA0KLSA8cmVmIGludGVybmFsPSIuLi4iLz4gY2FuIHJlZmVyZW5jZSBhIGJlYW4gaWQg
aW4gdGhlIHNhbWUgWE1MIGZpbGUgKGVxdWFsIHRvIHRoZSBmb3JtZXJseSBwcm9wb3NlZCAiYmVh
bi1pZCIsIHdpdGggYW4gWE1MIGlkcmVmIGNoZWNrKS4NCg0KUmVxdWVzdCBmb3IgY29tbWVudHMg
YWdhaW4gOi0pDQoNCkp1ZXJnZW4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv
bTogQ29saW4gU2FtcGFsZWFudSBbbWFpbHRvOmNvbGlubWwxQGV4aXMuY29tXQ0KU2VudDogTW9u
ZGF5LCBPY3RvYmVyIDIwLCAyMDAzIDEyOjUzIEFNDQpUbzogasO8cmdlbiBow7ZsbGVyIFt3ZXJr
M0FUXQ0KQ2M6IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0
DQpTdWJqZWN0OiBSZTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIFhNTCBiZWFuIHJlZmVy
ZW5jZXMNCg0KDQpJIHRoaW5rIHRoaXMgd291bGQgd29yaywgYW5kIGlzIHByb2JhYmx5IHRoZSBs
ZWFzdCBhbWJpZ3VvdXMuDQoNCmrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF0gd3JvdGU6DQoNCj5D
b2xpbiwgUm9kLA0KPiANCj5Zb3UncmUgcmlnaHQgcmVnYXJkaW5nIHRoZSB0ZXJtICJleHRlcm5h
bCIgZm9yIGEgZGlmZmVyZW50IFhNTCBmaWxlLCBub3Qgb25seSBhIGRpZmZlcmVudCBjb250ZXh0
LiBPbiBzZWNvbmQgdGhvdWdodCwgSSBjb25zaWRlciAiYmVhbi1pZCIgdW5jbGVhciB0b28sIGFz
IGJlYW5zIGluIG90aGVyIFhNTCBmaWxlcyBhbHNvIGhhdmUgYW4gImlkIi4gVGh1cywgYSBzbGln
aHRseSByZWZpbmVkIHN1Z2dlc3Rpb246DQo+IA0KPi0gPHJlZiBiZWFuPSIuLi4iLz4gY2FuIHJl
ZmVyZW5jZSBhbnkgYmVhbiBieSBhbnkgbmFtZSAoZXF1YWwgdG8gY3VycmVudCAiZXh0ZXJuYWwi
LCBzaW1pbGFyIHRvIGN1cnJlbnQgImJlYW4iIGJ1dCB3aXRob3V0IFhNTCBpZHJlZiBjaGVjayk7
DQo+IA0KPi0gPHJlZiBleHRlcm5hbD0iLi4uIi8+IHN0YXlzIGFzIGl0IGlzIGZvciB0aGUgdGlt
ZSBiZWluZywgYnV0IGluIGl0cyBmaW5hbCBpbmNhcm5hdGlvbiwgaXQgc2hvdWxkIGNoZWNrIHRo
YXQgdGhlIHJlZmVyZW5jZSBpcyByZWFsbHkgb3V0c2lkZSB0aGUgY3VycmVudCBYTUwgZmlsZTsN
Cj4gDQo+LSA8cmVmIGxvY2FsPSIuLi4iLz4gY2FuIHJlZmVyZW5jZSBhIGJlYW4gaWQgaW4gdGhl
IHNhbWUgWE1MIGZpbGUgKGVxdWFsIHRvIHRoZSBmb3JtZXJseSBwcm9wb3NlZCAiYmVhbi1pZCIs
IHdpdGggYW4gWE1MIGlkcmVmIGNoZWNrKS4NCj4gDQo+VGhhdCdzIHByb2JhYmx5IGFzIGVhc3kg
dG8gZXhwbGFpbiBhcyBwb3NzaWJsZTogImJlYW4iIGlzIHRoZSBnZW5lcmFsIG9uZSB0aGF0IGNh
biByZWZlcmVuY2UgYW55dGhpbmcsICJleHRlcm5hbCIgaXMgZm9yIGJlYW5zIG91dHNpZGUgdGhl
IGN1cnJlbnQgZmlsZSwgImxvY2FsIiBmb3IgYmVhbnMgaW5zaWRlIHRoZSBjdXJyZW50IGZpbGUg
LS0gYW5kIGl0J3Mgc3RpbGwgYmFja3dhcmQtY29tcGF0aWJsZS4gV2hhdCBkbyB5b3UgdGhpbms/
DQo+IA0KPkp1ZXJnZW4NCj4gDQo+IA0KPg0KPgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNo
dC0tLS0tIA0KPglWb246IENvbGluIFNhbXBhbGVhbnUgW21haWx0bzpjb2xpbm1sMUBleGlzLmNv
bV0gDQo+CUdlc2VuZGV0OiBTbyAxOS4xMC4yMDAzIDE2OjIwIA0KPglBbjogasO8cmdlbiBow7Zs
bGVyIFt3ZXJrM0FUXSANCj4JQ2M6IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291
cmNlZm9yZ2UubmV0IA0KPglCZXRyZWZmOiBSZTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJd
IFhNTCBiZWFuIHJlZmVyZW5jZXMNCj4JDQo+CQ0KPg0KPglqw7xyZ2VuIGjDtmxsZXIgW3dlcmsz
QVRdIHdyb3RlOg0KPgkNCj4JPkV2ZXJ5Ym9keSwNCj4JPg0KPgk+T24gdGhlIG9jY2FzaW9uIG9m
IGFsbG93aW5nIGEgc2luZ2xlIGFwcGxpY2F0aW9uIGNvbnRleHQgdG8gYmUgbG9hZGVkIGZyb20g
bXVsdGlwbGUgWE1MIGZpbGVzLCBJJ3ZlIHJlY29uc2lkZXJlZCBhIGRldGFpbCBvZiBvdXIgWE1M
IHN5bnRheDogVGhlICJyZWYiIHRhZyBjdXJyZW50bHkgaGFzIHR3byBkaWZmZXJlbnQgYXR0cmli
dXRlczoNCj4JPi0gImJlYW4iIHRvIHJlZmVyZW5jZSBhIGJlYW4gaW4gdGhlIHNhbWUgYXBwbGlj
YXRpb24gY29udGV4dCB2aWEgaXRzIGlkIGF0dHJpYnV0ZSAodGhlIFhNTCBpZCk7DQo+CT4tICJl
eHRlcm5hbCIgdG8gcmVmZXJlbmNlIGEgYmVhbiBpbiBhIHBhcmVudCBjb250ZXh0Lg0KPgk+VGhl
IGxhdHRlciBjYW4gYmFzaWNhbGx5IGFkZHJlc3MgYW55IGJlYW4sIGJlIGl0IGluIHRoZSBzYW1l
IGNvbnRleHQgb3IgYSBwYXJlbnQsIGFuIGlkIG9yIGFuIGFsaWFzIG5hbWUuDQo+CT4NCj4JPlRo
ZSBtYWluIHJhdGlvbmFsZSBiZWhpbmQgdGhlICJiZWFuIi8iZXh0ZXJuYWwiIHNlcGFyYXRpb24g
d2FzIHNpbXBseSBzZXBhcmF0aW5nIGJldHdlZW4gWE1MIHZhbGlkYXRpb24gb2YgaWQgcmVmcyAo
YnkgdGhlIFhNTCBwYXJzZXIpIGFuZCByZWZlcmVuY2luZyBhbnkga2luZCBvZiBuYW1lICh2YWxp
ZGF0ZWQgYnkgdGhlIGJlYW4gZmFjdG9yeSkuIFRoZSBsYXR0ZXIgd2FzIG1haW5seSBuZWNlc3Nh
cnkgZm9yIHJlZmVyZW5jaW5nIGJlYW5zIG91dHNpZGUgb2YgdGhlIGN1cnJlbnQgWE1MIGZpbGUs
IGF0IHRoYXQgdGltZSBhIHBhcmVudCBjb250ZXh0LiBJbiB0aGUgbWVhbiB0aW1lLCBhIHNpbmds
ZSBjb250ZXh0IGNhbiBiZSBkZWZpbmVkIGJ5IG11bHRpcGxlIFhNTCBmaWxlczsgdGh1cyBJIGRv
bid0IGNvbnNpZGVyIHRoZSAiYmVhbiIvImV4dGVybmFsIiBuYW1pbmcgYXBwcm9wcmlhdGUgYW55
bW9yZS4NCj4JPg0KPgk+SW5zdGVhZCwgbGV0IG1lIHN1Z2dlc3QgZGlmZmVyZW50IGF0dHJpYnV0
ZSBuYW1lczoNCj4JPi0ga2VlcCBhICJiZWFuIiBhdHRyaWJ1dGUgdG8gcmVmZXJlbmNlICphbnkq
IGtpbmQgb2YgbmFtZSwgYmUgaXQgaWQgb3IgYWxpYXMsIGp1c3QgbGlrZSB0aGUgY3VycmVudCAi
ZXh0ZXJuYWwiIGF0dHJpYnV0ZTsNCj4JPi0gaW50cm9kdWNlIGEgbmV3ICJiZWFuLWlkIiBhdHRy
aWJ1dGUgdG8gcmVmZXJlbmNlIGEgYmVhbiBpbiB0aGUgc2FtZSBYTUwgZmlsZSB2aWEgaXRzIFhN
TCBpZCwgbGlrZSB0aGUgY3VycmVudCAiYmVhbiIgYXR0cmlidXRlLg0KPgk+DQo+CT5JZiB3ZSBr
ZWVwIHRoZSAiZXh0ZXJuYWwiIGF0dHJpYnV0ZSBmb3IgdGhlIG1vbWVudCBhcyBhbiBlcXVpdmFs
ZW50IG9mIHRoZSBwcm9wb3NlZCAiYmVhbiIgYXR0cmlidXRlLCB0aGlzIHdvdWxkIGJlIGZ1bGx5
IGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBiZWFuIGRlZmluaXRpb24gZmlsZXMuIE9mIGNvdXJz
ZSwgImJlYW4iIGF0dHJpYnV0ZXMgd291bGQgbm90IGdldCB2YWxpZGF0ZWQgYnkgdGhlIFhNTCBw
YXJzZXIgYW55bW9yZSwgYnV0IHRoYXQgd291bGQgbm90IGJyZWFrIHRoZSBmaWxlcyBpbiBhbnkg
d2F5LiAiZXh0ZXJuYWwiIGF0dHJpYnV0ZXMgd291bGQgc3RpbGwgd29yayB0b28sIHRoZSBzYW1l
IGFzIGJlZm9yZS4NCj4JPg0KPgk+V2Ugc2hvdWxkIHJlY29tbWVuZCBtaWdyYXRpbmcgdG8gdGhl
IG5ldyBwYXR0ZXJuIHRob3VnaCwgaS5lLjoNCj4JPi0gcmVuYW1lICJiZWFuIiB0byAiYmVhbi1p
ZCI7DQo+CT4tIHJlbmFtZSAiZXh0ZXJuYWwiIHRvICJiZWFuIi4NCj4JPlRoYXQgc2hvdWxkIGJl
IGVhc3kgdG8gZG87IGFuZCBhcyB0aGUgb2xkIHBhdHRlcm4gc3RpbGwgd29ya3MsIHRoZXJlIGlz
IG5vIG5lZWQgdG8gbWlncmF0ZSBleGlzdGluZyBiZWFuIGRlZmluaXRpb24gZmlsZXMgaW1tZWRp
YXRlbHkuDQo+CT4NCj4JPkkndmUgdGhvdWdodCBhYm91dCB0aGlzIGZvciBhIHdoaWxlLCBhbmQg
SSBjb25zaWRlciBpdCB2ZXJ5IGltcG9ydGFudCB0byBjbGFyaWZ5IHRoZSBhdHRyaWJ1dGVzIGlu
IGEgd2F5IGxpa2UgdGhlIGFib3ZlLiBFbHNlLCBpdCB3aWxsIGJlIHByZXR0eSBoYXJkIHRvIGV4
cGxhaW4gdGhlIHJhdGlvbmFsZSBiZWhpbmQgImJlYW4iIGFuZCAiZXh0ZXJuYWwiLCBlc3BlY2lh
bGx5IHdoZW4gdXNpbmcgbXVsdGlwbGUgWE1MIGZpbGVzIGZvciBhIHNpbmdsZSBjb250ZXh0LiAi
YmVhbiIgYW5kICJiZWFuLWlkIiBhcmUgZmFyIGVhc2llciB0byBleHBsYWluOiAiYmVhbiIgYWx3
YXlzIHdvcmtzLCAiYmVhbi1pZCIgYWRkcyB2YWxpZGF0aW9uIGJ5IHRoZSBYTUwgcGFyc2VyIGlm
IHNwZWNpZnlpbmcgYSBiZWFuIGlkIGluIHRoZSBzYW1lIGNvbnRleHQuDQo+CT4NCj4JPkFueSB0
aG91Z2h0cyBvbiB0aGlzLCBhbnkgc3Ryb25nIG9iamVjdGlvbnM/IEkgd291bGQgYWN0dWFsbHkg
bGlrZSB0byBnZXQgdGhpcyBpbnRvIE0yLCBhbHRob3VnaCBpdCdzIHByZXR0eSBjbG9zZSBhbHJl
YWR5LiBBcyB0aGUgY2hhbmdlIGlzIHRyaXZpYWwgdG8gaW1wbGVtZW50IGFuZCBmdWxseSBiYWNr
d2FyZCBjb21wYXRpYmxlLCB0aGF0IHNob3VsZG4ndCBtYXR0ZXIgdG9vIG11Y2guDQo+CT4gDQo+
CT4NCj4JRXZlbiB0aGUgY3VycmVudCAnZXh0ZXJuYWwnIGNhbiBiZSBjb25zaWRlcmVkIHRvIHN0
aWxsIG1ha2Ugc2Vuc2UgaWYgeW91DQo+CXVzdCBjb25zaWRlciBpdCB0byBtZWFuIHRoZSBiZWFu
IHlvdSBhcmUgcmVmZXJpbmcgdG8gaXMgJ2V4dGVybmFsJyB0bw0KPgl0aGUgY3VycmVudCB4bWwg
ZmlsZSwgYXMgb3Bwb3NlZCB0byB0aGUgY3VycmVudCBkZWZpbml0aW9uLCB0aGF0IGlzIGl0DQo+
CWV4dGVybmFsIHRvIHRoZSBjdXJyZW50IGNvbnRleHQuDQo+CQ0KPglIb3dldmVyLCBJIGRvIGFn
cmVlIHRoYXQgaXQncyBwcm9iYWJseSBjbGVhbmVyIGFuZCBtYWtlcyBtb3JlIHNlbnNlIHRvDQo+
CWp1c3QgZ28gd2l0aCAnYmVhbicgYW5kICdiZWFuLWlkJywgYW5kIGVtcGhhc2l6ZSB0aGF0IHRo
ZSBsYXR0ZXIgc2hvdWxkDQo+CWJlIHVzZWQgaWYgcG9zc2libGUgZm9yIGV4dHJhIHZhbGlkYXRp
b24uLi4gVGhhdCBwb2ludCBzaG91bGQgZGVmaW5pdGVseQ0KPgliZSBkb2N1bWVudGVkIHByb3Bl
cmx5IChhbmQgdXNlZCBpbiB0aGUgZXhhbXBsZXMpLCBzbyBwZW9wbGUgZG9uJ3QNCj4JYWNjaWRl
bnRhbGx5IHRocm93IGF3YXkgdGhpcyBmcmVlIHZhbGlkYXRpb24gYnkgdXNpbmcganVzdCAnYmVh
bicuDQo+CQ0KPg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgU0YubmV0IGVtYWlsIHNwb25zb3JlZCBieTogRW50
ZXJwcmlzZSBMaW51eCBGb3J1bSBDb25mZXJlbmNlICYgRXhwbw0KVGhlIEV2ZW50IEZvciBMaW51
eCBEYXRhY2VudGVyIFNvbHV0aW9ucyAmIFN0cmF0ZWdpZXMgaW4gVGhlIEVudGVycHJpc2UgDQpM
aW51eCBpbiB0aGUgQm9hcmRyb29tOyBpbiB0aGUgRnJvbnQgT2ZmaWNlOyAmIGluIHRoZSBTZXJ2
ZXIgUm9vbSANCmh0dHA6Ly93d3cuZW50ZXJwcmlzZWxpbnV4Zm9ydW0uY29tDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU3ByaW5nZnJhbWV3b3JrLWRl
dmVsb3BlciBtYWlsaW5nIGxpc3QNClNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291
cmNlZm9yZ2UubmV0DQpodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5m
by9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQo=

Re: [Springframework-developer] Petclinic Hibernate implementation

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

Q29saW4sIFRyZXZvciwNCiANClNlc3Npb24uc2F2ZSBpbW1lZGlhdGVseSBpbnNlcnRzIHRoZSBv
YmplY3QgdG8gdGhlIGRhdGFiYXNlLCB0aGVyZWZvcmUgaXQgaXMgYWJsZSB0byBzZXQgaWQgaW50
byB0aGUgb2JqZWN0IGluIGFueSBjYXNlLiBBRkFJSywgU2Vzc2lvbi51cGRhdGUganVzdCBpbnNl
cnRzIHRoZSBvYmplY3QgaW50byB0aGUgU2Vzc2lvbidzIG9iamVjdCBjYWNoZSwgdG8gYmUgZmx1
c2hlZCBpbiB0aGUgbm9ybWFsIHdheS4gU28gU2Vzc2lvbi5zYXZlIHNlZW1zIHRvIHJlY2VpdmUg
c3BlY2lhbCB0cmVhdG1lbnQuDQogDQo+PmF1dG8taW5jcmVtZW50IGp1c3QgYWxsb3dzIHRvIHJl
YWQgaW4gdGhlIGFjdHVhbCBpZCBhZnRlcndhcmRzDQo+VGhpcyBpcyBub3QgcmVsaWFibGUgZm9y
IGNvbmN1cnJlbnQgaW5zZXJ0cyAod2hpY2ggaXMgd2h5IEkgZ2VuZXJhbGx5IHVzZSBzZXF1ZW5j
ZXMuICBGb3IgdGhlIHNhbXBsZSB0aGlzIHNob3VsZCBiZSBzdWZmaWNpZW50IHRob3VnaC4NCiAN
ClRoaXMgaXMgbm90IHJlbGlhYmxlIGV2ZW4gd2l0aCBwcm9wZXIgdHJhbnNhY3Rpb25zPyBTaG91
bGRuJ3QgImxhc3RfaW5zZXJ0X2lkIiBvciB3aGF0ZXZlciBpdCBpcyBjYWxsZWQgcmV0dXJuIHRo
ZSBsYXN0IGluc2VydGVkIGlkIGluIHRoZSBzYW1lIHRyYW5zYWN0aW9uLCBhbGxvd2luZyBmb3Ig
Y29uY3VycmVudCBpbnNlcnRzIGluIGRpZmZlcmVudCB0cmFuc2FjdGlvbnM/DQogDQpCYXNpY2Fs
bHksIHRoZSBjaGFuZ2UgZm9yIHRoZSBzYW1wbGUgd291bGQgYmUgc3RyYWlnaHRmb3J3YXJkOiBE
cm9wIGFsbCB0aGUgbWFudWFsbHkgaGFuZGxlZCBzZXF1ZW5jZSB0YWJsZXMgYW5kIHR1cm4gdGhl
IGlkIGNvbHVtbnMgaW50byBpZGVudGl0eSBjb2x1bW5zLiBUaGlzIHdvdWxkIGFsbG93IGZvciB1
c2luZyBIaWJlcm5hdGUncyBvdXQtb2YtdGhlLWJveCAiaWRlbnRpdHkiIHN0cmF0ZWd5OyB0aGUg
SkRCQyBpbXBsZW1lbnRhdGlvbiB3b3VsZCBoYXZlIHRvIGRvIG1hbnVhbCAibGFzdF9pbnNlcnRf
aWQiIHF1ZXJpZXMgYWZ0ZXIgdGhlIGFjdHVhbCBkb21haW4gaW5zZXJ0cy4NCiANCkp1ZXJnZW4N
CiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBDb2xpbiBT
YW1wYWxlYW51IFttYWlsdG86Y29saW5tbDFAZXhpcy5jb21dIA0KCUdlc2VuZGV0OiBNbyAyMC4x
MC4yMDAzIDA1OjI3IA0KCUFuOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJj
ZWZvcmdlLm5ldCANCglDYzogDQoJQmV0cmVmZjogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxv
cGVyXSBQZXRjbGluaWMgSGliZXJuYXRlIGltcGxlbWVudGF0aW9uDQoJDQoJDQoNCglqw7xyZ2Vu
IGjDtmxsZXIgW3dlcmszQVRdIHdyb3RlOg0KCQ0KCT5IaSBldmVyeWJvZHksDQoJPg0KCT4uLi4N
Cgk+DQoJPkJUVywgd2UgYXJlIHVzaW5nIGF1dG8taW5jcmVtZW50IGZvciBhbGwgTXlTUUwgZGF0
YWJhc2VzIGF0IHdlcmszQVQsIGFuZCBpdCB3b3JrcyBuaWNlbHkuIEknZCByZWFsbHkgbGlrZSB0
byB1bmRlcnN0YW5kIHRoZSByYXRpb25hbGUgZm9yIG1hbnVhbCBzZXF1ZW5jZSBoYW5kbGluZy4g
VGhlIG9ubHkgb25lIEkgc2VlIGlzIHRoYXQgdGhlIGlkIGNhbiBiZSBkZXRlcm1pbmVkIGJlZm9y
ZSB0aGUgZG9tYWluIGluc2VydC91cGRhdGUgc3RhdGVtZW50IHRoaXMgd2F5LCB3aGlsZSBhdXRv
LWluY3JlbWVudCBqdXN0IGFsbG93cyB0byByZWFkIGluIHRoZSBhY3R1YWwgaWQgYWZ0ZXJ3YXJk
cy4gQnV0IGRvZXMgdGhhdCByZWFsbHkgbWF0dGVyIGZvciBQZXRjbGluaWM/IFdvdWxkbid0IGl0
IGJlIGVhc2llciB0byB1c2UgYXV0by1pbmNyZW1lbnQvaWRlbnRpdHkgb24gYm90aCBNeVNRTCBh
bmQgSFNRTD8NCgk+DQoJPiANCgk+DQoJT25seSBzb21ld2hhdCByZWxhdGVkLCBidXQgaG93IGRv
ZXMgdGhlIGF1dG8taW5jcmVtZW50IGdldCBoYW5kbGVkDQoJdy9yZWdhcmRzIHRvIEhpYmVybmF0
ZSdzICdzYXZlJyBmdW5jdGlvbj8gVGhhdCBpcywgd2l0aCBhbiBPcmFjbGUNCglzZXF1ZW5jZSBv
ciBzb21lIG9mIHRoZSBvdGhlciAoaGkvbG8sIGV0Yy4pIHN0cmF0ZWdpZXMsIHdoZW4geW91IGNh
bGwNCglIaWJlcm5hdGUncyBzYXZlIGZ1bmN0aW9uLCB5b3VyIG9iamVjdHMgd2lsbCBnZXQgcHJv
cGVyIGlkcywgZXZlbiB0aG91Z2gNCgl0aGV5IGRvbid0IGdldCB3cml0dGVuIHRvIHRoZSBkYiB1
bnRpbCB0aGV5IGFjdHVhbGx5IGdldCBmbHVzaGVkLiBUaGlzDQoJaXMgYmVjYXVzZSB0aGUgZGIg
aGFzIGFscmVhZHkgYmVlbiBoaXQgZm9yIHRoZSBPcmFjbGUgc2VxdWVuY2Ugb3IgZm9yDQoJdGhl
IG1hbnVhbCBzZXF1ZW5jZSB0YWJsZSBjb2x1bW4uDQoJDQoJV2hhdCBoYXBwZW5zIGluIHlvdXIg
Y2FzZSB3aXRoIE15U1FMJ3MgYXV0by1pbmNyZW1lbnQgY29sdW1ucw0KCShlc3NlbnRpYWxseSBz
aW1pbGFyIHRvIFNRTCBTZXJ2ZXIncyBpZGVudGl0eSBjb2x1bW5zKS4gRG8gdGhlIElEcyBzdGF5
DQoJbnVsbCAob3Igd2hhdGV2ZXIgdGhlIHVuc2F2ZWQgdmFsdWUgaXMpIHVudGlsIEhpYmVybmF0
ZSdzIGZsdXNoIGFjdHVhbGx5DQoJZ2V0cyBjYWxsZWQ/DQoJIEp1c3QgY3VyaW91cyBzaW5jZSBJ
J3ZlIG5ldmVyIHVzZWQgZWl0aGVyIE15U1FMIG9yIFNRTCBTZXJ2ZXIgd2l0aA0KCUhpYmVybmF0
ZS4uLg0KCQ0KCUNvbGluDQoJDQoJDQoJDQoJdGVsbCBIaWJlcm5hdGUgdG8NCgkNCglIb3cgZG8g
eW91IHByb3Blcmx5IGhhbmRsZQ0KCQ0KCQ0KCT5UaGlzIGlzc3VlIGlzIHByZXR0eSB1cmdlbnQg
YWN0dWFsbHksIGFzIEknZCBsaWtlIHRvIGdldCBNMiBvdXQgbWlkIG5leHQgd2VlazsgdGhhdCdz
IGFscmVhZHkgc2xpZ2h0bHkgYmVoaW5kIHRoZSBvcmlnaW5hbCBzY2hlZHVsZSB3aXRoIGEgcmVs
ZWFzZSB0aGlzIHdlZWtlbmQuIEkgYmVsaWV2ZSB0aGF0IGEgd29ya2luZyBTcHJpbmcvSGliZXJu
YXRlIHNhbXBsZSAodGhlIG51bWJlciBvbmUgcXVlc3Rpb24gb24gdGhlIEhpYmVybmF0ZSBmb3J1
bXMpIGlzIHdvcnRoIGEgc2xpZ2h0IGRlbGF5LCB0aG91Z2guDQoJPg0KCT5KdWVyZ2VuDQoJPg0K
CT5QLlMuOg0KCT5KZWFuLVBpZXJyZSwgd2hhdCdzIHRoZSBzdGF0dXMgb2YgeW91ciBMaWdodC1D
b3VudHJpZXMgc2FtcGxlPyBEbyB3ZSByZWFsbHkgbmVlZCBpdD8gQ291bnRyaWVzIGNvbmZpZ3Vy
ZWQgdG8gdGhlIG1lbW9yeSBEQU8gc2hvdWxkIGJlIG5pY2UgZW5vdWdoLi4uIEkgZG8gbm90IGlu
dGVuZCB0byBpbmNsdWRlIGl0IGluIGRpc3RyaWJ1dGlvbnMsIGZvciB0aGUgdGltZSBiZWluZy4N
Cgk+DQoJPlAuUC5TLjogVG8gbWFrZSB0aGUgSGliZXJuYXRlIGltcGwgb2YgUGV0Y2xpbmljIHdv
cmsgb3V0LW9mLXRoZS1ib3gsIHdlIG5lZWQgdG8gc2hpcCB0aGUgbWFpbiBsaWJyYXJpZXMgb2Yg
SGliZXJuYXRlIDIuMC4zIHdpdGggU3ByaW5nLiBUaGF0J3MgMS42IGFkZGl0aW9uYWwgTUJzLCB3
aXRob3V0IHRoZSBKQ1MgY2FjaGUuIERvZXMgYW55b25lIG9iamVjdCB0byB0aGF0Pw0KCT4NCgk+
UC5QLlAuUy46DQoJPldoeSBpcyAiTXlTUUxNYXhWYWx1ZUluY3JlbWVudGVyIiB3cml0dGVuIHdp
dGggdXBwZXItY2FzZSAiU1FMIiBidXQgIkhzcWxNYXhWYWx1ZUluY3JlbWVudGVyIiBub3Q/IElz
IGl0IGp1c3QgYmVjYXVzZSBDVlMgZG9lc24ndCBzdXBwb3J0IGNhc2UgcmVuYW1pbmc/IDstKQ0K
CT4NCgk+Thg/SFnetemailspP3soPz9bP0k/ej9rP8eLP3s/Fj8/Kid9P96dx4TGmhM/Py96e0U/
Pz8/Q2rWnHp7Xj8qJT/YqD/ErT8/Xj8nPz90P3hJP3o/az/Hiz97Pz97YXgaGj8/P2g/Pxc/Pz8/
OT8/ceinthc/ej/erRooPxttPz8/Pwc/Pz8/Kx4/KT8/Pys/Zyg/Kms/eB8/Pz/Cij91P96WP14/
Zj8/KT8rLUo/Pwc/amc/Pz8dej8/PystPz8uP8efPz8ePz9hPz9sPz9iPz8sPz8/eT8rPz/etz9i
Pz8/PystP3c/Pz9rP3gfPz8/woo/dT/elj9ecj09PQ0KCT4NCgkNCgkNCgkNCgkNCgkNCgktLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJVGhp
cyBTRi5uZXQgZW1haWwgc3BvbnNvcmVkIGJ5OiBFbnRlcnByaXNlIExpbnV4IEZvcnVtIENvbmZl
cmVuY2UgJiBFeHBvDQoJVGhlIEV2ZW50IEZvciBMaW51eCBEYXRhY2VudGVyIFNvbHV0aW9ucyAm
IFN0cmF0ZWdpZXMgaW4gVGhlIEVudGVycHJpc2UNCglMaW51eCBpbiB0aGUgQm9hcmRyb29tOyBp
biB0aGUgRnJvbnQgT2ZmaWNlOyAmIGluIHRoZSBTZXJ2ZXIgUm9vbQ0KCWh0dHA6Ly93d3cuZW50
ZXJwcmlzZWxpbnV4Zm9ydW0uY29tDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcgbGlzdA0K
CVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJaHR0cHM6
Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3JrLWRl
dmVsb3Blcg0KCQ0KDQo=

Re: [Springframework-developer] Petclinic Hibernate implementation

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

jürgen höller [werk3AT] wrote:

>Hi everybody,
> 
>...
> 
>BTW, we are using auto-increment for all MySQL databases at werk3AT, and it works nicely. I'd really like to understand the rationale for manual sequence handling. The only one I see is that the id can be determined before the domain insert/update statement this way, while auto-increment just allows to read in the actual id afterwards. But does that really matter for Petclinic? Wouldn't it be easier to use auto-increment/identity on both MySQL and HSQL?
> 
>  
>
Only somewhat related, but how does the auto-increment get handled 
w/regards to Hibernate's 'save' function? That is, with an Oracle 
sequence or some of the other (hi/lo, etc.) strategies, when you call 
Hibernate's save function, your objects will get proper ids, even though 
they don't get written to the db until they actually get flushed. This 
is because the db has already been hit for the Oracle sequence or for 
the manual sequence table column.

What happens in your case with MySQL's auto-increment columns 
(essentially similar to SQL Server's identity columns). Do the IDs stay 
null (or whatever the unsaved value is) until Hibernate's flush actually 
gets called?
 Just curious since I've never used either MySQL or SQL Server with 
Hibernate...

Colin



tell Hibernate to

How do you properly handle


>This issue is pretty urgent actually, as I'd like to get M2 out mid next week; that's already slightly behind the original schedule with a release this weekend. I believe that a working Spring/Hibernate sample (the number one question on the Hibernate forums) is worth a slight delay, though.
> 
>Juergen
> 
>P.S.:
>Jean-Pierre, what's the status of your Light-Countries sample? Do we really need it? Countries configured to the memory DAO should be nice enough... I do not intend to include it in distributions, for the time being.
> 
>P.P.S.: To make the Hibernate impl of Petclinic work out-of-the-box, we need to ship the main libraries of Hibernate 2.0.3 with Spring. That's 1.6 additional MBs, without the JCS cache. Does anyone object to that?
> 
>P.P.P.S.:
>Why is "MySQLMaxValueIncrementer" written with upper-case "SQL" but "HsqlMaxValueIncrementer" not? Is it just because CVS doesn't support case renaming? ;-)
> 
>N?HY޵隊[)?{(??[?I?z?k?Nj?{???*'}?ޝDŽƚ??/z{E????Cj֜z{^?*%?ب?ĭ??^?'??t?xI?z?k?Nj?{??{ax???h??????9??q觶?z?ޭ(?m????????+?)???+?g(?*k?x???Š?u?ޖ?^?f??)?+-J???jg???z???+-??.?ǟ????a??l??b??,???y?+??޷?b????+-?w???k?x???Š?u?ޖ?^r===
>

RE: [Springframework-developer] Petclinic Hibernate implementation

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

Cool.  I might actually be able to learn more about Hibernate now (lots =
of desire, absolutely no time :) ).

>>auto-increment just allows to read in the actual id afterwards
This is not reliable for concurrent inserts (which is why I generally =
use sequences.  For the sample this should be sufficient though.

Trevor

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=C3=BCrgen h=C3=B6ller [werk3AT]
Sent: October 19, 2003 6:48 PM
To: spr...@li...
Subject: [Springframework-developer] Petclinic Hibernate implementation


Hi everybody,
=20
I've just finished something that I wanted to get in M2: a Hibernate =
implementation of Petclinic! The main rationale is to provide a working =
Spring/Hibernate sample app -- adapting Petclinic was the easiest way. =
And it's nice to switch between the JDBC implementation and the =
Hibernate one... The new impl is basically just an alternative =
implementation of the Clinic business interface, but I've generally =
refined that interface and the domain objects in the course of the work. =
I've also renamed the root package from "petclinic" to =
"org.springframework.samples.petclinic", analogous to the countries =
demo.
=20
Generally, everything works nicely so far on both implementations. =
There's one issue though: HsqlJdbcClinic uses HsqlMaxValueIncrementer =
for id generation, with one sequence table per domain table. Hibernate =
doesn't have a similar id generation strategy, so I'm wondering what to =
do to make both impls work on the same database. The Hibernate docs say =
that HSQL supports "identity" for id columns; why are we not using this =
for HsqlJdbcClinic too? I.e. making the id columns identity columns and =
getting rid of all the sequence tables. I guess there's a drawback with =
this; can anyone shed some light on the issue?
=20
BTW, we are using auto-increment for all MySQL databases at werk3AT, and =
it works nicely. I'd really like to understand the rationale for manual =
sequence handling. The only one I see is that the id can be determined =
before the domain insert/update statement this way, while auto-increment =
just allows to read in the actual id afterwards. But does that really =
matter for Petclinic? Wouldn't it be easier to use =
auto-increment/identity on both MySQL and HSQL?
=20
This issue is pretty urgent actually, as I'd like to get M2 out mid next =
week; that's already slightly behind the original schedule with a =
release this weekend. I believe that a working Spring/Hibernate sample =
(the number one question on the Hibernate forums) is worth a slight =
delay, though.
=20
Juergen
=20
P.S.:
Jean-Pierre, what's the status of your Light-Countries sample? Do we =
really need it? Countries configured to the memory DAO should be nice =
enough... I do not intend to include it in distributions, for the time =
being.
=20
P.P.S.: To make the Hibernate impl of Petclinic work out-of-the-box, we =
need to ship the main libraries of Hibernate 2.0.3 with Spring. That's =
1.6 additional MBs, without the JCS cache. Does anyone object to that?
=20
P.P.P.S.:
Why is "MySQLMaxValueIncrementer" written with upper-case "SQL" but =
"HsqlMaxValueIncrementer" not? Is it just because CVS doesn't support =
case renaming? ;-)
=20
                     +=12=17 ?[){([ ' +=1E.) Z+??`zw=1E Li8^=12Z+.) =
6??ig [ +kj?"8^=12{^?  b^=06?v(=17?9 q {ay' ?  0  +=1E) +o o             =
    *kx=1F  ?zZ)zXX*kx=1F? ?zZ)z l .a=1Ew i +-(=1E~ { b ?+-w k?x=1F? =
?zZ)

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.525 / Virus Database: 322 - Release Date: 09/10/2003

Re: [Springframework-developer] XML bean references

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

I think this would work, and is probably the least ambiguous.

jürgen höller [werk3AT] wrote:

>Colin, Rod,
> 
>You're right regarding the term "external" for a different XML file, not only a different context. On second thought, I consider "bean-id" unclear too, as beans in other XML files also have an "id". Thus, a slightly refined suggestion:
> 
>- <ref bean="..."/> can reference any bean by any name (equal to current "external", similar to current "bean" but without XML idref check);
> 
>- <ref external="..."/> stays as it is for the time being, but in its final incarnation, it should check that the reference is really outside the current XML file;
> 
>- <ref local="..."/> can reference a bean id in the same XML file (equal to the formerly proposed "bean-id", with an XML idref check).
> 
>That's probably as easy to explain as possible: "bean" is the general one that can reference anything, "external" is for beans outside the current file, "local" for beans inside the current file -- and it's still backward-compatible. What do you think?
> 
>Juergen
> 
> 
>
>	-----Ursprüngliche Nachricht----- 
>	Von: Colin Sampaleanu [mailto:col...@ex...] 
>	Gesendet: So 19.10.2003 16:20 
>	An: jürgen höller [werk3AT] 
>	Cc: spr...@li... 
>	Betreff: Re: [Springframework-developer] XML bean references
>	
>	
>
>	jürgen höller [werk3AT] wrote:
>	
>	>Everybody,
>	>
>	>On the occasion of allowing a single application context to be loaded from multiple XML files, I've reconsidered a detail of our XML syntax: The "ref" tag currently has two different attributes:
>	>- "bean" to reference a bean in the same application context via its id attribute (the XML id);
>	>- "external" to reference a bean in a parent context.
>	>The latter can basically address any bean, be it in the same context or a parent, an id or an alias name.
>	>
>	>The main rationale behind the "bean"/"external" separation was simply separating between XML validation of id refs (by the XML parser) and referencing any kind of name (validated by the bean factory). The latter was mainly necessary for referencing beans outside of the current XML file, at that time a parent context. In the mean time, a single context can be defined by multiple XML files; thus I don't consider the "bean"/"external" naming appropriate anymore.
>	>
>	>Instead, let me suggest different attribute names:
>	>- keep a "bean" attribute to reference *any* kind of name, be it id or alias, just like the current "external" attribute;
>	>- introduce a new "bean-id" attribute to reference a bean in the same XML file via its XML id, like the current "bean" attribute.
>	>
>	>If we keep the "external" attribute for the moment as an equivalent of the proposed "bean" attribute, this would be fully compatible with existing bean definition files. Of course, "bean" attributes would not get validated by the XML parser anymore, but that would not break the files in any way. "external" attributes would still work too, the same as before.
>	>
>	>We should recommend migrating to the new pattern though, i.e.:
>	>- rename "bean" to "bean-id";
>	>- rename "external" to "bean".
>	>That should be easy to do; and as the old pattern still works, there is no need to migrate existing bean definition files immediately.
>	>
>	>I've thought about this for a while, and I consider it very important to clarify the attributes in a way like the above. Else, it will be pretty hard to explain the rationale behind "bean" and "external", especially when using multiple XML files for a single context. "bean" and "bean-id" are far easier to explain: "bean" always works, "bean-id" adds validation by the XML parser if specifying a bean id in the same context.
>	>
>	>Any thoughts on this, any strong objections? I would actually like to get this into M2, although it's pretty close already. As the change is trivial to implement and fully backward compatible, that shouldn't matter too much.
>	> 
>	>
>	Even the current 'external' can be considered to still make sense if you
>	ust consider it to mean the bean you are refering to is 'external' to
>	the current xml file, as opposed to the current definition, that is it
>	external to the current context.
>	
>	However, I do agree that it's probably cleaner and makes more sense to
>	just go with 'bean' and 'bean-id', and emphasize that the latter should
>	be used if possible for extra validation... That point should definitely
>	be documented properly (and used in the examples), so people don't
>	accidentally throw away this free validation by using just 'bean'.
>	
>

[Springframework-developer] Petclinic Hibernate implementation

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

SGkgZXZlcnlib2R5LA0KIA0KSSd2ZSBqdXN0IGZpbmlzaGVkIHNvbWV0aGluZyB0aGF0IEkgd2Fu
dGVkIHRvIGdldCBpbiBNMjogYSBIaWJlcm5hdGUgaW1wbGVtZW50YXRpb24gb2YgUGV0Y2xpbmlj
ISBUaGUgbWFpbiByYXRpb25hbGUgaXMgdG8gcHJvdmlkZSBhIHdvcmtpbmcgU3ByaW5nL0hpYmVy
bmF0ZSBzYW1wbGUgYXBwIC0tIGFkYXB0aW5nIFBldGNsaW5pYyB3YXMgdGhlIGVhc2llc3Qgd2F5
LiBBbmQgaXQncyBuaWNlIHRvIHN3aXRjaCBiZXR3ZWVuIHRoZSBKREJDIGltcGxlbWVudGF0aW9u
IGFuZCB0aGUgSGliZXJuYXRlIG9uZS4uLiBUaGUgbmV3IGltcGwgaXMgYmFzaWNhbGx5IGp1c3Qg
YW4gYWx0ZXJuYXRpdmUgaW1wbGVtZW50YXRpb24gb2YgdGhlIENsaW5pYyBidXNpbmVzcyBpbnRl
cmZhY2UsIGJ1dCBJJ3ZlIGdlbmVyYWxseSByZWZpbmVkIHRoYXQgaW50ZXJmYWNlIGFuZCB0aGUg
ZG9tYWluIG9iamVjdHMgaW4gdGhlIGNvdXJzZSBvZiB0aGUgd29yay4gSSd2ZSBhbHNvIHJlbmFt
ZWQgdGhlIHJvb3QgcGFja2FnZSBmcm9tICJwZXRjbGluaWMiIHRvICJvcmcuc3ByaW5nZnJhbWV3
b3JrLnNhbXBsZXMucGV0Y2xpbmljIiwgYW5hbG9nb3VzIHRvIHRoZSBjb3VudHJpZXMgZGVtby4N
CiANCkdlbmVyYWxseSwgZXZlcnl0aGluZyB3b3JrcyBuaWNlbHkgc28gZmFyIG9uIGJvdGggaW1w
bGVtZW50YXRpb25zLiBUaGVyZSdzIG9uZSBpc3N1ZSB0aG91Z2g6IEhzcWxKZGJjQ2xpbmljIHVz
ZXMgSHNxbE1heFZhbHVlSW5jcmVtZW50ZXIgZm9yIGlkIGdlbmVyYXRpb24sIHdpdGggb25lIHNl
cXVlbmNlIHRhYmxlIHBlciBkb21haW4gdGFibGUuIEhpYmVybmF0ZSBkb2Vzbid0IGhhdmUgYSBz
aW1pbGFyIGlkIGdlbmVyYXRpb24gc3RyYXRlZ3ksIHNvIEknbSB3b25kZXJpbmcgd2hhdCB0byBk
byB0byBtYWtlIGJvdGggaW1wbHMgd29yayBvbiB0aGUgc2FtZSBkYXRhYmFzZS4gVGhlIEhpYmVy
bmF0ZSBkb2NzIHNheSB0aGF0IEhTUUwgc3VwcG9ydHMgImlkZW50aXR5IiBmb3IgaWQgY29sdW1u
czsgd2h5IGFyZSB3ZSBub3QgdXNpbmcgdGhpcyBmb3IgSHNxbEpkYmNDbGluaWMgdG9vPyBJLmUu
IG1ha2luZyB0aGUgaWQgY29sdW1ucyBpZGVudGl0eSBjb2x1bW5zIGFuZCBnZXR0aW5nIHJpZCBv
ZiBhbGwgdGhlIHNlcXVlbmNlIHRhYmxlcy4gSSBndWVzcyB0aGVyZSdzIGEgZHJhd2JhY2sgd2l0
aCB0aGlzOyBjYW4gYW55b25lIHNoZWQgc29tZSBsaWdodCBvbiB0aGUgaXNzdWU/DQogDQpCVFcs
IHdlIGFyZSB1c2luZyBhdXRvLWluY3JlbWVudCBmb3IgYWxsIE15U1FMIGRhdGFiYXNlcyBhdCB3
ZXJrM0FULCBhbmQgaXQgd29ya3MgbmljZWx5LiBJJ2QgcmVhbGx5IGxpa2UgdG8gdW5kZXJzdGFu
ZCB0aGUgcmF0aW9uYWxlIGZvciBtYW51YWwgc2VxdWVuY2UgaGFuZGxpbmcuIFRoZSBvbmx5IG9u
ZSBJIHNlZSBpcyB0aGF0IHRoZSBpZCBjYW4gYmUgZGV0ZXJtaW5lZCBiZWZvcmUgdGhlIGRvbWFp
biBpbnNlcnQvdXBkYXRlIHN0YXRlbWVudCB0aGlzIHdheSwgd2hpbGUgYXV0by1pbmNyZW1lbnQg
anVzdCBhbGxvd3MgdG8gcmVhZCBpbiB0aGUgYWN0dWFsIGlkIGFmdGVyd2FyZHMuIEJ1dCBkb2Vz
IHRoYXQgcmVhbGx5IG1hdHRlciBmb3IgUGV0Y2xpbmljPyBXb3VsZG4ndCBpdCBiZSBlYXNpZXIg
dG8gdXNlIGF1dG8taW5jcmVtZW50L2lkZW50aXR5IG9uIGJvdGggTXlTUUwgYW5kIEhTUUw/DQog
DQpUaGlzIGlzc3VlIGlzIHByZXR0eSB1cmdlbnQgYWN0dWFsbHksIGFzIEknZCBsaWtlIHRvIGdl
dCBNMiBvdXQgbWlkIG5leHQgd2VlazsgdGhhdCdzIGFscmVhZHkgc2xpZ2h0bHkgYmVoaW5kIHRo
ZSBvcmlnaW5hbCBzY2hlZHVsZSB3aXRoIGEgcmVsZWFzZSB0aGlzIHdlZWtlbmQuIEkgYmVsaWV2
ZSB0aGF0IGEgd29ya2luZyBTcHJpbmcvSGliZXJuYXRlIHNhbXBsZSAodGhlIG51bWJlciBvbmUg
cXVlc3Rpb24gb24gdGhlIEhpYmVybmF0ZSBmb3J1bXMpIGlzIHdvcnRoIGEgc2xpZ2h0IGRlbGF5
LCB0aG91Z2guDQogDQpKdWVyZ2VuDQogDQpQLlMuOg0KSmVhbi1QaWVycmUsIHdoYXQncyB0aGUg
c3RhdHVzIG9mIHlvdXIgTGlnaHQtQ291bnRyaWVzIHNhbXBsZT8gRG8gd2UgcmVhbGx5IG5lZWQg
aXQ/IENvdW50cmllcyBjb25maWd1cmVkIHRvIHRoZSBtZW1vcnkgREFPIHNob3VsZCBiZSBuaWNl
IGVub3VnaC4uLiBJIGRvIG5vdCBpbnRlbmQgdG8gaW5jbHVkZSBpdCBpbiBkaXN0cmlidXRpb25z
LCBmb3IgdGhlIHRpbWUgYmVpbmcuDQogDQpQLlAuUy46IFRvIG1ha2UgdGhlIEhpYmVybmF0ZSBp
bXBsIG9mIFBldGNsaW5pYyB3b3JrIG91dC1vZi10aGUtYm94LCB3ZSBuZWVkIHRvIHNoaXAgdGhl
IG1haW4gbGlicmFyaWVzIG9mIEhpYmVybmF0ZSAyLjAuMyB3aXRoIFNwcmluZy4gVGhhdCdzIDEu
NiBhZGRpdGlvbmFsIE1Ccywgd2l0aG91dCB0aGUgSkNTIGNhY2hlLiBEb2VzIGFueW9uZSBvYmpl
Y3QgdG8gdGhhdD8NCiANClAuUC5QLlMuOg0KV2h5IGlzICJNeVNRTE1heFZhbHVlSW5jcmVtZW50
ZXIiIHdyaXR0ZW4gd2l0aCB1cHBlci1jYXNlICJTUUwiIGJ1dCAiSHNxbE1heFZhbHVlSW5jcmVt
ZW50ZXIiIG5vdD8gSXMgaXQganVzdCBiZWNhdXNlIENWUyBkb2Vzbid0IHN1cHBvcnQgY2FzZSBy
ZW5hbWluZz8gOy0pDQogDQo=

[Springframework-developer] StringUtils.arrayToCommaDelimitedString

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

This also applies to StringUtils.collectionToCommaDelimitedString

With csv files, there is normally escaping if the field contains either a
quote or a comma.  For example:

VALUE				ESCAPED
Bob				Bob
dog,cat			"dog,cat"
The "funny" house		"The ""funny"" house"

The current methods in StringUtils don't handle these cases.  I have
implemented this escaping for output, and I'm wondering if it's worth adding
to Spring.  If so, should I change the current methods to support escaping,
or simply add escaping methods (such as String[] escapeArray(Object[]
array) ).  I'd prefer to modify the current methods, but want to make sure
it won't adversely affect anyone.  If we do change those methods, I will
also fix the reverse methods.

Trevor D. Cook

Re: [Springframework-developer] XML bean references

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

Q29saW4sIFJvZCwNCiANCllvdSdyZSByaWdodCByZWdhcmRpbmcgdGhlIHRlcm0gImV4dGVybmFs
IiBmb3IgYSBkaWZmZXJlbnQgWE1MIGZpbGUsIG5vdCBvbmx5IGEgZGlmZmVyZW50IGNvbnRleHQu
IE9uIHNlY29uZCB0aG91Z2h0LCBJIGNvbnNpZGVyICJiZWFuLWlkIiB1bmNsZWFyIHRvbywgYXMg
YmVhbnMgaW4gb3RoZXIgWE1MIGZpbGVzIGFsc28gaGF2ZSBhbiAiaWQiLiBUaHVzLCBhIHNsaWdo
dGx5IHJlZmluZWQgc3VnZ2VzdGlvbjoNCiANCi0gPHJlZiBiZWFuPSIuLi4iLz4gY2FuIHJlZmVy
ZW5jZSBhbnkgYmVhbiBieSBhbnkgbmFtZSAoZXF1YWwgdG8gY3VycmVudCAiZXh0ZXJuYWwiLCBz
aW1pbGFyIHRvIGN1cnJlbnQgImJlYW4iIGJ1dCB3aXRob3V0IFhNTCBpZHJlZiBjaGVjayk7DQog
DQotIDxyZWYgZXh0ZXJuYWw9Ii4uLiIvPiBzdGF5cyBhcyBpdCBpcyBmb3IgdGhlIHRpbWUgYmVp
bmcsIGJ1dCBpbiBpdHMgZmluYWwgaW5jYXJuYXRpb24sIGl0IHNob3VsZCBjaGVjayB0aGF0IHRo
ZSByZWZlcmVuY2UgaXMgcmVhbGx5IG91dHNpZGUgdGhlIGN1cnJlbnQgWE1MIGZpbGU7DQogDQot
IDxyZWYgbG9jYWw9Ii4uLiIvPiBjYW4gcmVmZXJlbmNlIGEgYmVhbiBpZCBpbiB0aGUgc2FtZSBY
TUwgZmlsZSAoZXF1YWwgdG8gdGhlIGZvcm1lcmx5IHByb3Bvc2VkICJiZWFuLWlkIiwgd2l0aCBh
biBYTUwgaWRyZWYgY2hlY2spLg0KIA0KVGhhdCdzIHByb2JhYmx5IGFzIGVhc3kgdG8gZXhwbGFp
biBhcyBwb3NzaWJsZTogImJlYW4iIGlzIHRoZSBnZW5lcmFsIG9uZSB0aGF0IGNhbiByZWZlcmVu
Y2UgYW55dGhpbmcsICJleHRlcm5hbCIgaXMgZm9yIGJlYW5zIG91dHNpZGUgdGhlIGN1cnJlbnQg
ZmlsZSwgImxvY2FsIiBmb3IgYmVhbnMgaW5zaWRlIHRoZSBjdXJyZW50IGZpbGUgLS0gYW5kIGl0
J3Mgc3RpbGwgYmFja3dhcmQtY29tcGF0aWJsZS4gV2hhdCBkbyB5b3UgdGhpbms/DQogDQpKdWVy
Z2VuDQogDQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjog
Q29saW4gU2FtcGFsZWFudSBbbWFpbHRvOmNvbGlubWwxQGV4aXMuY29tXSANCglHZXNlbmRldDog
U28gMTkuMTAuMjAwMyAxNjoyMCANCglBbjogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXSANCglD
Yzogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQoJQmV0
cmVmZjogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBYTUwgYmVhbiByZWZlcmVuY2Vz
DQoJDQoJDQoNCglqw7xyZ2VuIGjDtmxsZXIgW3dlcmszQVRdIHdyb3RlOg0KCQ0KCT5FdmVyeWJv
ZHksDQoJPg0KCT5PbiB0aGUgb2NjYXNpb24gb2YgYWxsb3dpbmcgYSBzaW5nbGUgYXBwbGljYXRp
b24gY29udGV4dCB0byBiZSBsb2FkZWQgZnJvbSBtdWx0aXBsZSBYTUwgZmlsZXMsIEkndmUgcmVj
b25zaWRlcmVkIGEgZGV0YWlsIG9mIG91ciBYTUwgc3ludGF4OiBUaGUgInJlZiIgdGFnIGN1cnJl
bnRseSBoYXMgdHdvIGRpZmZlcmVudCBhdHRyaWJ1dGVzOg0KCT4tICJiZWFuIiB0byByZWZlcmVu
Y2UgYSBiZWFuIGluIHRoZSBzYW1lIGFwcGxpY2F0aW9uIGNvbnRleHQgdmlhIGl0cyBpZCBhdHRy
aWJ1dGUgKHRoZSBYTUwgaWQpOw0KCT4tICJleHRlcm5hbCIgdG8gcmVmZXJlbmNlIGEgYmVhbiBp
biBhIHBhcmVudCBjb250ZXh0Lg0KCT5UaGUgbGF0dGVyIGNhbiBiYXNpY2FsbHkgYWRkcmVzcyBh
bnkgYmVhbiwgYmUgaXQgaW4gdGhlIHNhbWUgY29udGV4dCBvciBhIHBhcmVudCwgYW4gaWQgb3Ig
YW4gYWxpYXMgbmFtZS4NCgk+DQoJPlRoZSBtYWluIHJhdGlvbmFsZSBiZWhpbmQgdGhlICJiZWFu
Ii8iZXh0ZXJuYWwiIHNlcGFyYXRpb24gd2FzIHNpbXBseSBzZXBhcmF0aW5nIGJldHdlZW4gWE1M
IHZhbGlkYXRpb24gb2YgaWQgcmVmcyAoYnkgdGhlIFhNTCBwYXJzZXIpIGFuZCByZWZlcmVuY2lu
ZyBhbnkga2luZCBvZiBuYW1lICh2YWxpZGF0ZWQgYnkgdGhlIGJlYW4gZmFjdG9yeSkuIFRoZSBs
YXR0ZXIgd2FzIG1haW5seSBuZWNlc3NhcnkgZm9yIHJlZmVyZW5jaW5nIGJlYW5zIG91dHNpZGUg
b2YgdGhlIGN1cnJlbnQgWE1MIGZpbGUsIGF0IHRoYXQgdGltZSBhIHBhcmVudCBjb250ZXh0LiBJ
biB0aGUgbWVhbiB0aW1lLCBhIHNpbmdsZSBjb250ZXh0IGNhbiBiZSBkZWZpbmVkIGJ5IG11bHRp
cGxlIFhNTCBmaWxlczsgdGh1cyBJIGRvbid0IGNvbnNpZGVyIHRoZSAiYmVhbiIvImV4dGVybmFs
IiBuYW1pbmcgYXBwcm9wcmlhdGUgYW55bW9yZS4NCgk+DQoJPkluc3RlYWQsIGxldCBtZSBzdWdn
ZXN0IGRpZmZlcmVudCBhdHRyaWJ1dGUgbmFtZXM6DQoJPi0ga2VlcCBhICJiZWFuIiBhdHRyaWJ1
dGUgdG8gcmVmZXJlbmNlICphbnkqIGtpbmQgb2YgbmFtZSwgYmUgaXQgaWQgb3IgYWxpYXMsIGp1
c3QgbGlrZSB0aGUgY3VycmVudCAiZXh0ZXJuYWwiIGF0dHJpYnV0ZTsNCgk+LSBpbnRyb2R1Y2Ug
YSBuZXcgImJlYW4taWQiIGF0dHJpYnV0ZSB0byByZWZlcmVuY2UgYSBiZWFuIGluIHRoZSBzYW1l
IFhNTCBmaWxlIHZpYSBpdHMgWE1MIGlkLCBsaWtlIHRoZSBjdXJyZW50ICJiZWFuIiBhdHRyaWJ1
dGUuDQoJPg0KCT5JZiB3ZSBrZWVwIHRoZSAiZXh0ZXJuYWwiIGF0dHJpYnV0ZSBmb3IgdGhlIG1v
bWVudCBhcyBhbiBlcXVpdmFsZW50IG9mIHRoZSBwcm9wb3NlZCAiYmVhbiIgYXR0cmlidXRlLCB0
aGlzIHdvdWxkIGJlIGZ1bGx5IGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBiZWFuIGRlZmluaXRp
b24gZmlsZXMuIE9mIGNvdXJzZSwgImJlYW4iIGF0dHJpYnV0ZXMgd291bGQgbm90IGdldCB2YWxp
ZGF0ZWQgYnkgdGhlIFhNTCBwYXJzZXIgYW55bW9yZSwgYnV0IHRoYXQgd291bGQgbm90IGJyZWFr
IHRoZSBmaWxlcyBpbiBhbnkgd2F5LiAiZXh0ZXJuYWwiIGF0dHJpYnV0ZXMgd291bGQgc3RpbGwg
d29yayB0b28sIHRoZSBzYW1lIGFzIGJlZm9yZS4NCgk+DQoJPldlIHNob3VsZCByZWNvbW1lbmQg
bWlncmF0aW5nIHRvIHRoZSBuZXcgcGF0dGVybiB0aG91Z2gsIGkuZS46DQoJPi0gcmVuYW1lICJi
ZWFuIiB0byAiYmVhbi1pZCI7DQoJPi0gcmVuYW1lICJleHRlcm5hbCIgdG8gImJlYW4iLg0KCT5U
aGF0IHNob3VsZCBiZSBlYXN5IHRvIGRvOyBhbmQgYXMgdGhlIG9sZCBwYXR0ZXJuIHN0aWxsIHdv
cmtzLCB0aGVyZSBpcyBubyBuZWVkIHRvIG1pZ3JhdGUgZXhpc3RpbmcgYmVhbiBkZWZpbml0aW9u
IGZpbGVzIGltbWVkaWF0ZWx5Lg0KCT4NCgk+SSd2ZSB0aG91Z2h0IGFib3V0IHRoaXMgZm9yIGEg
d2hpbGUsIGFuZCBJIGNvbnNpZGVyIGl0IHZlcnkgaW1wb3J0YW50IHRvIGNsYXJpZnkgdGhlIGF0
dHJpYnV0ZXMgaW4gYSB3YXkgbGlrZSB0aGUgYWJvdmUuIEVsc2UsIGl0IHdpbGwgYmUgcHJldHR5
IGhhcmQgdG8gZXhwbGFpbiB0aGUgcmF0aW9uYWxlIGJlaGluZCAiYmVhbiIgYW5kICJleHRlcm5h
bCIsIGVzcGVjaWFsbHkgd2hlbiB1c2luZyBtdWx0aXBsZSBYTUwgZmlsZXMgZm9yIGEgc2luZ2xl
IGNvbnRleHQuICJiZWFuIiBhbmQgImJlYW4taWQiIGFyZSBmYXIgZWFzaWVyIHRvIGV4cGxhaW46
ICJiZWFuIiBhbHdheXMgd29ya3MsICJiZWFuLWlkIiBhZGRzIHZhbGlkYXRpb24gYnkgdGhlIFhN
TCBwYXJzZXIgaWYgc3BlY2lmeWluZyBhIGJlYW4gaWQgaW4gdGhlIHNhbWUgY29udGV4dC4NCgk+
DQoJPkFueSB0aG91Z2h0cyBvbiB0aGlzLCBhbnkgc3Ryb25nIG9iamVjdGlvbnM/IEkgd291bGQg
YWN0dWFsbHkgbGlrZSB0byBnZXQgdGhpcyBpbnRvIE0yLCBhbHRob3VnaCBpdCdzIHByZXR0eSBj
bG9zZSBhbHJlYWR5LiBBcyB0aGUgY2hhbmdlIGlzIHRyaXZpYWwgdG8gaW1wbGVtZW50IGFuZCBm
dWxseSBiYWNrd2FyZCBjb21wYXRpYmxlLCB0aGF0IHNob3VsZG4ndCBtYXR0ZXIgdG9vIG11Y2gu
DQoJPiANCgk+DQoJRXZlbiB0aGUgY3VycmVudCAnZXh0ZXJuYWwnIGNhbiBiZSBjb25zaWRlcmVk
IHRvIHN0aWxsIG1ha2Ugc2Vuc2UgaWYgeW91DQoJdXN0IGNvbnNpZGVyIGl0IHRvIG1lYW4gdGhl
IGJlYW4geW91IGFyZSByZWZlcmluZyB0byBpcyAnZXh0ZXJuYWwnIHRvDQoJdGhlIGN1cnJlbnQg
eG1sIGZpbGUsIGFzIG9wcG9zZWQgdG8gdGhlIGN1cnJlbnQgZGVmaW5pdGlvbiwgdGhhdCBpcyBp
dA0KCWV4dGVybmFsIHRvIHRoZSBjdXJyZW50IGNvbnRleHQuDQoJDQoJSG93ZXZlciwgSSBkbyBh
Z3JlZSB0aGF0IGl0J3MgcHJvYmFibHkgY2xlYW5lciBhbmQgbWFrZXMgbW9yZSBzZW5zZSB0bw0K
CWp1c3QgZ28gd2l0aCAnYmVhbicgYW5kICdiZWFuLWlkJywgYW5kIGVtcGhhc2l6ZSB0aGF0IHRo
ZSBsYXR0ZXIgc2hvdWxkDQoJYmUgdXNlZCBpZiBwb3NzaWJsZSBmb3IgZXh0cmEgdmFsaWRhdGlv
bi4uLiBUaGF0IHBvaW50IHNob3VsZCBkZWZpbml0ZWx5DQoJYmUgZG9jdW1lbnRlZCBwcm9wZXJs
eSAoYW5kIHVzZWQgaW4gdGhlIGV4YW1wbGVzKSwgc28gcGVvcGxlIGRvbid0DQoJYWNjaWRlbnRh
bGx5IHRocm93IGF3YXkgdGhpcyBmcmVlIHZhbGlkYXRpb24gYnkgdXNpbmcganVzdCAnYmVhbicu
DQoJDQoJDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgU0YubmV0IGVtYWlsIHNwb25zb3JlZCBieTogRW50ZXJw
cmlzZSBMaW51eCBGb3J1bSBDb25mZXJlbmNlICYgRXhwbw0KCVRoZSBFdmVudCBGb3IgTGludXgg
RGF0YWNlbnRlciBTb2x1dGlvbnMgJiBTdHJhdGVnaWVzIGluIFRoZSBFbnRlcnByaXNlDQoJTGlu
dXggaW4gdGhlIEJvYXJkcm9vbTsgaW4gdGhlIEZyb250IE9mZmljZTsgJiBpbiB0aGUgU2VydmVy
IFJvb20NCglodHRwOi8vd3d3LmVudGVycHJpc2VsaW51eGZvcnVtLmNvbQ0KCV9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJU3ByaW5nZnJhbWV3b3JrLWRl
dmVsb3BlciBtYWlsaW5nIGxpc3QNCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNv
dXJjZWZvcmdlLm5ldA0KCWh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3Rp
bmZvL3NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXINCgkNCg0K

RE: [Springframework-developer] XML bean references

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

+1

Trevor

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=C3=BCrgen h=C3=B6ller [werk3AT]
Sent: October 18, 2003 5:42 PM
To: spr...@li...
Subject: [Springframework-developer] XML bean references


Everybody,
=20
On the occasion of allowing a single application context to be loaded =
from multiple XML files, I've reconsidered a detail of our XML syntax: =
The "ref" tag currently has two different attributes:
- "bean" to reference a bean in the same application context via its id =
attribute (the XML id);
- "external" to reference a bean in a parent context.
The latter can basically address any bean, be it in the same context or =
a parent, an id or an alias name.
=20
The main rationale behind the "bean"/"external" separation was simply =
separating between XML validation of id refs (by the XML parser) and =
referencing any kind of name (validated by the bean factory). The latter =
was mainly necessary for referencing beans outside of the current XML =
file, at that time a parent context. In the mean time, a single context =
can be defined by multiple XML files; thus I don't consider the =
"bean"/"external" naming appropriate anymore.
=20
Instead, let me suggest different attribute names:
- keep a "bean" attribute to reference *any* kind of name, be it id or =
alias, just like the current "external" attribute;
- introduce a new "bean-id" attribute to reference a bean in the same =
XML file via its XML id, like the current "bean" attribute.
=20
If we keep the "external" attribute for the moment as an equivalent of =
the proposed "bean" attribute, this would be fully compatible with =
existing bean definition files. Of course, "bean" attributes would not =
get validated by the XML parser anymore, but that would not break the =
files in any way. "external" attributes would still work too, the same =
as before.
=20
We should recommend migrating to the new pattern though, i.e.:
- rename "bean" to "bean-id";
- rename "external" to "bean".
That should be easy to do; and as the old pattern still works, there is =
no need to migrate existing bean definition files immediately.
=20
I've thought about this for a while, and I consider it very important to =
clarify the attributes in a way like the above. Else, it will be pretty =
hard to explain the rationale behind "bean" and "external", especially =
when using multiple XML files for a single context. "bean" and "bean-id" =
are far easier to explain: "bean" always works, "bean-id" adds =
validation by the XML parser if specifying a bean id in the same =
context.
=20
Any thoughts on this, any strong objections? I would actually like to =
get this into M2, although it's pretty close already. As the change is =
trivial to implement and fully backward compatible, that shouldn't =
matter too much.
=20
Juergen
=20
P.S.:
The same issue exists with the rarely used "parent" attribute of the =
"bean" tag. Currently, "parent" can reference any kind of name; we could =
introduce the above pattern a la "parent" and "parent-id" for the sake =
of consistency.
=20
                     +=12=17 ?[){([ ' +=1E.) Z+??`zw=1E Li8^=12Z+.) =
6??ig [ +kj?"8^=12{^?  b^=06?v(=17?9 q {ay' ?  0  +=1E) +o o             =
    *kx=1F  ?zZ)zXX*kx=1F? ?zZ)z l .a=1Ew i +-(=1E~ { b ?+-w k?x=1F? =
?zZ)

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.525 / Virus Database: 322 - Release Date: 09/10/2003

Re: [Springframework-developer] XML bean references

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

jürgen höller [werk3AT] wrote:

>Everybody,
> 
>On the occasion of allowing a single application context to be loaded from multiple XML files, I've reconsidered a detail of our XML syntax: The "ref" tag currently has two different attributes:
>- "bean" to reference a bean in the same application context via its id attribute (the XML id);
>- "external" to reference a bean in a parent context.
>The latter can basically address any bean, be it in the same context or a parent, an id or an alias name.
> 
>The main rationale behind the "bean"/"external" separation was simply separating between XML validation of id refs (by the XML parser) and referencing any kind of name (validated by the bean factory). The latter was mainly necessary for referencing beans outside of the current XML file, at that time a parent context. In the mean time, a single context can be defined by multiple XML files; thus I don't consider the "bean"/"external" naming appropriate anymore.
> 
>Instead, let me suggest different attribute names:
>- keep a "bean" attribute to reference *any* kind of name, be it id or alias, just like the current "external" attribute;
>- introduce a new "bean-id" attribute to reference a bean in the same XML file via its XML id, like the current "bean" attribute.
> 
>If we keep the "external" attribute for the moment as an equivalent of the proposed "bean" attribute, this would be fully compatible with existing bean definition files. Of course, "bean" attributes would not get validated by the XML parser anymore, but that would not break the files in any way. "external" attributes would still work too, the same as before.
> 
>We should recommend migrating to the new pattern though, i.e.:
>- rename "bean" to "bean-id";
>- rename "external" to "bean".
>That should be easy to do; and as the old pattern still works, there is no need to migrate existing bean definition files immediately.
> 
>I've thought about this for a while, and I consider it very important to clarify the attributes in a way like the above. Else, it will be pretty hard to explain the rationale behind "bean" and "external", especially when using multiple XML files for a single context. "bean" and "bean-id" are far easier to explain: "bean" always works, "bean-id" adds validation by the XML parser if specifying a bean id in the same context.
> 
>Any thoughts on this, any strong objections? I would actually like to get this into M2, although it's pretty close already. As the change is trivial to implement and fully backward compatible, that shouldn't matter too much.
>  
>
Even the current 'external' can be considered to still make sense if you 
ust consider it to mean the bean you are refering to is 'external' to 
the current xml file, as opposed to the current definition, that is it 
external to the current context.

However, I do agree that it's probably cleaner and makes more sense to 
just go with 'bean' and 'bean-id', and emphasize that the latter should 
be used if possible for extra validation... That point should definitely 
be documented properly (and used in the examples), so people don't 
accidentally throw away this free validation by using just 'bean'.

[Springframework-developer] Another TSS article

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

Patrick's blog has been posted on TSS, so maybe another discussion will
start (the previous one on Rod's article seems to have died down, but maybe
it's just the weekend).  I read the comparison between Spring/WebWork he
wrote, and he actually seems to have spent a good amount of time/thought on
it, so take a look.
http://www.theserverside.com/home/thread.jsp?thread_id=21962

As far as the actual comparison goes, I think he did a fair job.  Spring
seems to come out ahead, and he lists our "weakness" (or areas where Webwork
is superior in his opinion) as:

- more flexible component lifecycles (request, session or application)
- simple configuration (which he specifies as "For a small number of
frequently used components, Webwork will require less configuration")
- more IDEA refactoring friendly

I think he's definately right about the "IDEA refactoring friendly" which I
translate as IDE-friendly (which would include Eclipse).  We've already
discussed our desire to have plugins in the future, so this isn't an unknown
issue.

As far as simple configuration, I haven't used WebWork2, so I'll take his
word for it.  Having introduced a number of developers to Spring I can
accept this (although I didn't have problems), although I wonder if it
applies to larger projects as well.  I'll be posting about this on TSS to
find out.

As far as "more flexible component lifecycles", maybe someone else can
comment (on list or on TSS), since I am unfamiliar with how WebWork
specifies it's cycles.  Generally I just use Spring for configuration,
request/session scoping is handled inside each controller.

Trevor

[Springframework-developer] XML bean references

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

RXZlcnlib2R5LA0KIA0KT24gdGhlIG9jY2FzaW9uIG9mIGFsbG93aW5nIGEgc2luZ2xlIGFwcGxp
Y2F0aW9uIGNvbnRleHQgdG8gYmUgbG9hZGVkIGZyb20gbXVsdGlwbGUgWE1MIGZpbGVzLCBJJ3Zl
IHJlY29uc2lkZXJlZCBhIGRldGFpbCBvZiBvdXIgWE1MIHN5bnRheDogVGhlICJyZWYiIHRhZyBj
dXJyZW50bHkgaGFzIHR3byBkaWZmZXJlbnQgYXR0cmlidXRlczoNCi0gImJlYW4iIHRvIHJlZmVy
ZW5jZSBhIGJlYW4gaW4gdGhlIHNhbWUgYXBwbGljYXRpb24gY29udGV4dCB2aWEgaXRzIGlkIGF0
dHJpYnV0ZSAodGhlIFhNTCBpZCk7DQotICJleHRlcm5hbCIgdG8gcmVmZXJlbmNlIGEgYmVhbiBp
biBhIHBhcmVudCBjb250ZXh0Lg0KVGhlIGxhdHRlciBjYW4gYmFzaWNhbGx5IGFkZHJlc3MgYW55
IGJlYW4sIGJlIGl0IGluIHRoZSBzYW1lIGNvbnRleHQgb3IgYSBwYXJlbnQsIGFuIGlkIG9yIGFu
IGFsaWFzIG5hbWUuDQogDQpUaGUgbWFpbiByYXRpb25hbGUgYmVoaW5kIHRoZSAiYmVhbiIvImV4
dGVybmFsIiBzZXBhcmF0aW9uIHdhcyBzaW1wbHkgc2VwYXJhdGluZyBiZXR3ZWVuIFhNTCB2YWxp
ZGF0aW9uIG9mIGlkIHJlZnMgKGJ5IHRoZSBYTUwgcGFyc2VyKSBhbmQgcmVmZXJlbmNpbmcgYW55
IGtpbmQgb2YgbmFtZSAodmFsaWRhdGVkIGJ5IHRoZSBiZWFuIGZhY3RvcnkpLiBUaGUgbGF0dGVy
IHdhcyBtYWlubHkgbmVjZXNzYXJ5IGZvciByZWZlcmVuY2luZyBiZWFucyBvdXRzaWRlIG9mIHRo
ZSBjdXJyZW50IFhNTCBmaWxlLCBhdCB0aGF0IHRpbWUgYSBwYXJlbnQgY29udGV4dC4gSW4gdGhl
IG1lYW4gdGltZSwgYSBzaW5nbGUgY29udGV4dCBjYW4gYmUgZGVmaW5lZCBieSBtdWx0aXBsZSBY
TUwgZmlsZXM7IHRodXMgSSBkb24ndCBjb25zaWRlciB0aGUgImJlYW4iLyJleHRlcm5hbCIgbmFt
aW5nIGFwcHJvcHJpYXRlIGFueW1vcmUuDQogDQpJbnN0ZWFkLCBsZXQgbWUgc3VnZ2VzdCBkaWZm
ZXJlbnQgYXR0cmlidXRlIG5hbWVzOg0KLSBrZWVwIGEgImJlYW4iIGF0dHJpYnV0ZSB0byByZWZl
cmVuY2UgKmFueSoga2luZCBvZiBuYW1lLCBiZSBpdCBpZCBvciBhbGlhcywganVzdCBsaWtlIHRo
ZSBjdXJyZW50ICJleHRlcm5hbCIgYXR0cmlidXRlOw0KLSBpbnRyb2R1Y2UgYSBuZXcgImJlYW4t
aWQiIGF0dHJpYnV0ZSB0byByZWZlcmVuY2UgYSBiZWFuIGluIHRoZSBzYW1lIFhNTCBmaWxlIHZp
YSBpdHMgWE1MIGlkLCBsaWtlIHRoZSBjdXJyZW50ICJiZWFuIiBhdHRyaWJ1dGUuDQogDQpJZiB3
ZSBrZWVwIHRoZSAiZXh0ZXJuYWwiIGF0dHJpYnV0ZSBmb3IgdGhlIG1vbWVudCBhcyBhbiBlcXVp
dmFsZW50IG9mIHRoZSBwcm9wb3NlZCAiYmVhbiIgYXR0cmlidXRlLCB0aGlzIHdvdWxkIGJlIGZ1
bGx5IGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBiZWFuIGRlZmluaXRpb24gZmlsZXMuIE9mIGNv
dXJzZSwgImJlYW4iIGF0dHJpYnV0ZXMgd291bGQgbm90IGdldCB2YWxpZGF0ZWQgYnkgdGhlIFhN
TCBwYXJzZXIgYW55bW9yZSwgYnV0IHRoYXQgd291bGQgbm90IGJyZWFrIHRoZSBmaWxlcyBpbiBh
bnkgd2F5LiAiZXh0ZXJuYWwiIGF0dHJpYnV0ZXMgd291bGQgc3RpbGwgd29yayB0b28sIHRoZSBz
YW1lIGFzIGJlZm9yZS4NCiANCldlIHNob3VsZCByZWNvbW1lbmQgbWlncmF0aW5nIHRvIHRoZSBu
ZXcgcGF0dGVybiB0aG91Z2gsIGkuZS46DQotIHJlbmFtZSAiYmVhbiIgdG8gImJlYW4taWQiOw0K
LSByZW5hbWUgImV4dGVybmFsIiB0byAiYmVhbiIuDQpUaGF0IHNob3VsZCBiZSBlYXN5IHRvIGRv
OyBhbmQgYXMgdGhlIG9sZCBwYXR0ZXJuIHN0aWxsIHdvcmtzLCB0aGVyZSBpcyBubyBuZWVkIHRv
IG1pZ3JhdGUgZXhpc3RpbmcgYmVhbiBkZWZpbml0aW9uIGZpbGVzIGltbWVkaWF0ZWx5Lg0KIA0K
SSd2ZSB0aG91Z2h0IGFib3V0IHRoaXMgZm9yIGEgd2hpbGUsIGFuZCBJIGNvbnNpZGVyIGl0IHZl
cnkgaW1wb3J0YW50IHRvIGNsYXJpZnkgdGhlIGF0dHJpYnV0ZXMgaW4gYSB3YXkgbGlrZSB0aGUg
YWJvdmUuIEVsc2UsIGl0IHdpbGwgYmUgcHJldHR5IGhhcmQgdG8gZXhwbGFpbiB0aGUgcmF0aW9u
YWxlIGJlaGluZCAiYmVhbiIgYW5kICJleHRlcm5hbCIsIGVzcGVjaWFsbHkgd2hlbiB1c2luZyBt
dWx0aXBsZSBYTUwgZmlsZXMgZm9yIGEgc2luZ2xlIGNvbnRleHQuICJiZWFuIiBhbmQgImJlYW4t
aWQiIGFyZSBmYXIgZWFzaWVyIHRvIGV4cGxhaW46ICJiZWFuIiBhbHdheXMgd29ya3MsICJiZWFu
LWlkIiBhZGRzIHZhbGlkYXRpb24gYnkgdGhlIFhNTCBwYXJzZXIgaWYgc3BlY2lmeWluZyBhIGJl
YW4gaWQgaW4gdGhlIHNhbWUgY29udGV4dC4NCiANCkFueSB0aG91Z2h0cyBvbiB0aGlzLCBhbnkg
c3Ryb25nIG9iamVjdGlvbnM/IEkgd291bGQgYWN0dWFsbHkgbGlrZSB0byBnZXQgdGhpcyBpbnRv
IE0yLCBhbHRob3VnaCBpdCdzIHByZXR0eSBjbG9zZSBhbHJlYWR5LiBBcyB0aGUgY2hhbmdlIGlz
IHRyaXZpYWwgdG8gaW1wbGVtZW50IGFuZCBmdWxseSBiYWNrd2FyZCBjb21wYXRpYmxlLCB0aGF0
IHNob3VsZG4ndCBtYXR0ZXIgdG9vIG11Y2guDQogDQpKdWVyZ2VuDQogDQpQLlMuOg0KVGhlIHNh
bWUgaXNzdWUgZXhpc3RzIHdpdGggdGhlIHJhcmVseSB1c2VkICJwYXJlbnQiIGF0dHJpYnV0ZSBv
ZiB0aGUgImJlYW4iIHRhZy4gQ3VycmVudGx5LCAicGFyZW50IiBjYW4gcmVmZXJlbmNlIGFueSBr
aW5kIG9mIG5hbWU7IHdlIGNvdWxkIGludHJvZHVjZSB0aGUgYWJvdmUgcGF0dGVybiBhIGxhICJw
YXJlbnQiIGFuZCAicGFyZW50LWlkIiBmb3IgdGhlIHNha2Ugb2YgY29uc2lzdGVuY3kuDQogDQo=

[Springframework-developer] MVC-step-by-step test suite

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

VGhvbWFzLA0KIA0KSGF2ZSB5b3UgcmV3b3JrZWQgdGhlIE1WQy1zdGVwLWJ5LXN0ZXAgdHV0b3Jp
YWwgcmVnYXJkaW5nIHRoZSB0ZXN0IHN1aXRlPyBUaGVyZSBoYXMgYmVlbiB0aGUgaXNzdWUgd2l0
aCB0aGUgd2ViIGZyYW1ld29ya3Mgb2JqZWN0cyBub3cgcmVxdWlyaW5nIGEgV2ViQXBwbGljYXRp
b25Db250ZXh0IGR1ZSB0byB0aGUgMS4wLU0xLWludHJvZHVjZWQgV2ViQXBwbGljYXRpb25PYmpl
Y3RTdXBwb3J0LiBJJ3ZlIGJlZW4gdGhlIG9uZSB0aGF0IGludHJvZHVjZWQgdGhhdCwgdW5mb3J0
dW5hdGVseSBiZWluZyB1bmF3YXJlIG9mIHRoZSBzaWRlIGVmZmVjdCBvbiB0aGUgdHV0b3JpYWw7
IEkgc3RpbGwgY29uc2lkZXIgaXQgbW9yZSBjb3JyZWN0IHRvIHJlcXVpcmUgYSBXZWJBcHBsaWNh
dGlvbkNvbnRleHQgdGhvdWdoLiBUaGVyZSBpcyBzdGlsbCBhIGJ1ZyBlbnRyeSBvbiB0aGlzIGF0
IFNvdXJjZUZvcmdlOyBoYXMgdGhpcyBiZWVuIHJlc29sdmVkIG5vdz8NCiANCkp1ZXJnZW4NCg==