springframework-developer — Spring Framework developers list

Re: [Springframework-developer] DTD

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

Rod,

> I've just checked in a new version of the beans DTD. There are no functional
> changes, but it has much improved Javadoc.
> 
> Can we please get the latest version from CVS onto our website--it should
> help users get to grips with beans XML files.
> 

It's there now.

Thomas

Re: [Springframework-developer] Re: [Springframework-user] applicationContext.xml for servlet 2.2

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

> Frankly, I haven't been aware that the listeners have been our only
Servlet 2.3 dependency. But the main reason for removing the loader servlet
was consistency: We also got WebAppRootListener and Log4jConfigListener, and
splitting each of them into a listener, a servlet, and a delegate class too
seemed like overkill. Do you see any need for this?

AFAIK we've never used anything else from 2.3.

Regards,
Rod

[Springframework-developer] DTD

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

I've just checked in a new version of the beans DTD. There are no functional
changes, but it has much improved Javadoc.

Can we please get the latest version from CVS onto our website--it should
help users get to grips with beans XML files.

Regards,
Rod

[Springframework-developer] Package switch

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

I think we should switch to the new package structure sooner rather than
later. This way our next release will be well after all the bugs due to the
migration are smoothed out.

Does anyone have stuff to commit first? I've just committed a change (beans
DTD) but I'm happy to stay out of CVS until it's done.

Regards,
Rod

[Springframework-developer] Re: [Springframework-user] applicationContext.xml for servlet 2.2

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

SGkgRGFycmVuLA0KIA0KWW91J3JlIGFjdHVhbGx5IHRoZSBmaXJzdCBvbmUgdG8gYXNrIGZvciBy
ZXZpdmluZyBDb250ZXh0TG9hZGVyU2VydmxldCA7LSkgQnV0IGFueXdheSwgeW91IGdvdCBhIHBv
aW50IHdpdGggbGFyZ2UgY29ycG9yYXRpb25zIGFuZCB0aGVpciBsYWdnaW5nIGJlaGluZCBpbiB0
ZXJtcyBvZiB1cGRhdGVzLiBJJ3ZlIGFscmVhZHkgcmUtYWRkZWQgdGhlIGxvYWRlciBzZXJ2bGV0
LCBJJ2xsIGNvbW1pdCBpdCB0b21vcnJvdy4NCiANCk9mIGNvdXJzZSwgdGhlIENvbnRleHRMb2Fk
ZXIgZGVsZWdhdGUgYWxyZWFkeSBhbGxvd2VkIGJlaW5nIGNhbGxlZCBpbiBhIHNpbmdsZSBsaW5l
IGZyb20gd2l0aGluIGEgY3VzdG9tIHN0YXJ0dXAgc2VydmxldC4gU28gd2UncmUgbm93IHJlLWFk
ZGluZyBDb250ZXh0TG9hZGVyU2VydmxldCBmb3IgcHVyZSBjb252ZW5pZW5jZSBvbiBTZXJ2bGV0
IDIuMiwgdG8gYXZvaWQgdGhlIG5lZWQgZm9yIGEgY3VzdG9tIHN0YXJ0dXAgc2VydmxldCB3aXRo
IGEgQ29udGV4dExvYWRlci5pbml0Q29udGV4dCBjYWxsLg0KIA0KRnJhbmtseSwgSSBoYXZlbid0
IGJlZW4gYXdhcmUgdGhhdCB0aGUgbGlzdGVuZXJzIGhhdmUgYmVlbiBvdXIgb25seSBTZXJ2bGV0
IDIuMyBkZXBlbmRlbmN5LiBCdXQgdGhlIG1haW4gcmVhc29uIGZvciByZW1vdmluZyB0aGUgbG9h
ZGVyIHNlcnZsZXQgd2FzIGNvbnNpc3RlbmN5OiBXZSBhbHNvIGdvdCBXZWJBcHBSb290TGlzdGVu
ZXIgYW5kIExvZzRqQ29uZmlnTGlzdGVuZXIsIGFuZCBzcGxpdHRpbmcgZWFjaCBvZiB0aGVtIGlu
dG8gYSBsaXN0ZW5lciwgYSBzZXJ2bGV0LCBhbmQgYSBkZWxlZ2F0ZSBjbGFzcyB0b28gc2VlbWVk
IGxpa2Ugb3ZlcmtpbGwuIERvIHlvdSBzZWUgYW55IG5lZWQgZm9yIHRoaXM/DQogDQpMb2c0akNv
bmZpZ0xpc3RlbmVyIGlzIGp1c3QgbmVjZXNzYXJ5IGZvciBjdXN0b20gY29uZmlnIGZpbGUgbG9j
YXRpb25zIGFuZCBjb25maWcgbW9kaWZpY2F0aW9uIGRldGVjdGlvbi4gSXQgaW5jbHVkZXMgdGhl
IGZ1bmN0aW9uYWxpdHkgb2YgV2ViQXBwUm9vdExpc3RlbmVyLCB3aGljaCBleHBvcnRzIHRoZSB3
ZWIgYXBwIHJvb3QgZGlyZWN0b3J5IHRvIGEgc3lzdGVtIHByb3BlcnR5LCBtYWlubHkgZm9yIHVz
ZSB3aXRoaW4gTG9nNEogbG9nIGZpbGUgcGF0aHMgKGEgbGEgJHt3ZWJhcHAucm9vdH0vV0VCLUlO
Ri9teWxvZy50eHQgdG8gZ2V0IGEgbG9nIGZpbGUgd2l0aGluIHRoZSB3ZWIgYXBwKS4NCiANClJl
Z2FyZHMsDQpKdWVyZ2VuDQogDQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0t
LS0tIA0KCVZvbjogZGFycmVuLmRhdmlzb25AaHNiY2liLmNvbSBbbWFpbHRvOmRhcnJlbi5kYXZp
c29uQGhzYmNpYi5jb21dIA0KCUdlc2VuZGV0OiBNbyAxMS4wOC4yMDAzIDE3OjQwIA0KCUFuOiBz
cHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCANCglDYzogDQoJ
QmV0cmVmZjogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIFJlOiBbU3ByaW5nZnJhbWV3b3Jr
LXVzZXJdIGFwcGxpY2F0aW9uQ29udGV4dC54bWwgZm9yIHNlcnZsZXQgMi4yDQoJDQoJDQoNCg0K
DQoJV291bGQgdGhlcmUgYmUgYW55IGludGVyZXN0IGluIHJldml2aW5nIHRoZSBza2VsZXRvbiBv
ZiB0aGUgb2xkIGkyMSBzZXJ2bGV0DQoJdGhhdCB1c2VkIHRvIGRvIHRoaXMsIGp1c3QgZm9yIHRo
ZSBzYWtlIG9mIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IC0gYXQNCglsZWFzdCBmb3IgYSB3aGls
ZT8gIEkga25vdyBpdCAqaXMqIGEgc3RlcCBiYWNrd2FyZHMsIGJ1dCBtYW55IGxhcmdlDQoJY29y
cG9yYXRpb25zIGRvIGhhdmUgYSBoYWJpdCBvZiBtb3ZpbmcgcmVsdWN0YW50bHkgdG8gbmV3ZXIg
dmVyc2lvbnMgb2YNCglhcHBsaWNhdGlvbiBzZXJ2ZXJzIGFuZCBwbGVudHkgbWF5IGFwcHJlY2lh
dGUgdGhlIGdlc3R1cmUuICBTZWVtcyBhIHNoYW1lDQoJdG8gcHVzaCB0aGlzIGZyYW1ld29yayBh
Y3Rpdml0eSBpbnRvIHRoZSBhcHBsaWNhdGlvbiBkb21haW4gd2hlbiBpdCdzIG9ubHkNCglhIGRv
emVuIGxpbmVzIG9mIGNvZGUgYW5kIGl0IGxvb2tzIHRvIGJlIHRoZSBvbmx5IHRoaW5nIHByZXZl
bnRpbmcgc2VydmxldA0KCTIuMiBjb21wYXRpYmlsaXR5IGZvciB0aGUgTVZDIGNvZGViYXNlLg0K
CQ0KCUF0dGFjaGVkIGlzIGEgbW9kaWZpZWQgdmVyc2lvbiBvZiB0aGUgc2VydmxldCB3aXRoIHN1
aXRhYmxlIEBkZXByZWNhdGVkDQoJdGFncyBhbmQgY29tbWVudHMgZm9yIGNvbnNpZGVyYXRpb24u
ICBJdCBzaG91bGQgaGF2ZSBubyBpbXBhY3Qgb24gYW55DQoJZXhpc3RpbmcgY29kZSBmcm9tIDAu
OS4xDQoJDQoJQWxsIHRoZSBiZXN0LA0KCURhcnJlbi4NCgkNCgkoU2VlIGF0dGFjaGVkIGZpbGU6
IENvbnRleHRMb2FkZXJTZXJ2bGV0LmphdmEpDQoJDQoJPHF1b3RlPg0KCUhpIERhcnJlbiwNCgkN
CglZb3UncmUgcmlnaHQsIFNwcmluZyBhc3N1bWVzIFNlcnZsZXQgMi4zIGluIHRoYXQgaXQgcmVj
b21tZW5kcyBsaXN0ZW5lcnMNCglmb3Igc3RhcnR1cCB3b3JrLCBsaWtlIENvbnRleHRMb2FkZXJM
aXN0ZW5lciBhbmQgTG9nNGpDb25maWdMaXN0ZW5lci4gV2UNCgljb21waWxlIGFnYWluc3QgU2Vy
dmxldCAyLjMsIHNvIHRoZXJlIG1pZ2h0IGJlIHNvbWUgb3RoZXIgZGVwZW5kZW5jaWVzIHRvbywN
CglidXQgbm9uZSB0aGF0IEkgY2FuIHRoaW5rIG9mIGF0IHRoZSBtb21lbnQuDQoJDQoJSWYgeW91
IGxvb2sgYXQgdGhlIGltcGxlbWVudGF0aW9uIG9mIENvbnRleHRMb2FkZXJMaXN0ZW5lciwgeW91
J2xsIGZpbmQNCgl0aGF0IGl0IGp1c3QgZGVsZWdhdGVzIHRoZSBjb250ZXh0SW5pdGlhbGl6ZWQg
ZXZlbnQgdG8NCglDb250ZXh0TG9hZGVyLmluaXRDb250ZXh0KGV2ZW50LmdldFNlcnZsZXRDb250
ZXh0KCkpLiBTbyBpbiBhIFNlcnZsZXQgMi4yDQoJY29udGFpbmVyLCB5b3UgY291bGQgd3JpdGUg
eW91ciBvd24gbG9hZC1vbi1zdGFydHVwIHNlcnZsZXQgdGhhdCBpbnZva2VzDQoJQ29udGV4dExv
YWRlci5pbml0Q29udGV4dCBpbiBpdHMgaW5pdCBtZXRob2QsIGFtb25nIG90aGVyIGN1c3RvbSBz
dGFydHVwDQoJd29yayB0aGF0IHlvdSBtYXkgcmVxdWlyZSwgbGlrZSBMb2c0SiBpbml0aWFsaXph
dGlvbi4NCgkNCglSZWdhcmRzLA0KCUp1ZXJnZW4NCgkNCgkNCgkNCgkgLS0tLS1VcnNwcsO8bmds
aWNoZSBOYWNocmljaHQtLS0tLQ0KCSBWb246IERhcnJlbiBEYXZpc29uIFttYWlsdG86ZGFycmVu
QGRhdmlzb24udWsubmV0XQ0KCSBHZXNlbmRldDogU28gMTAuMDguMjAwMyAyMToxOQ0KCSBBbjog
c3ByaW5nZnJhbWV3b3JrLXVzZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJIENjOg0KCSBCZXRy
ZWZmOiBbU3ByaW5nZnJhbWV3b3JrLXVzZXJdIGFwcGxpY2F0aW9uQ29udGV4dC54bWwgZm9yIHNl
cnZsZXQgMi4yDQoJDQoJDQoJDQoJIGhpLA0KCQ0KCSBBbGwgb2YgdGhlIGV4YW1wbGUgd2ViIHBy
b2plY3RzIGxvYWQgdGhlIGFwcGxpY2F0aW9uQ29udGV4dCB3aXRoIGENCgkNCgkgPGxpc3RlbmVy
Pg0KCSAgIDxsaXN0ZW5lci1jbGFzcz4NCgkgICAgIGNvbS5pbnRlcmZhY2UyMS53ZWIuY29udGV4
dC5Db250ZXh0TG9hZGVyTGlzdGVuZXINCgkgICA8L2xpc3RlbmVyLWNsYXNzPg0KCSA8L2xpc3Rl
bmVyPg0KCQ0KCSB3aGljaCBpcyBzZXJ2bGV0IDIuMyBzcGVjaWZpYy4gIElzIHRoZXJlIGEgc3Vw
cG9ydGVkL3JlY29tbWVuZGVkIHdheSB0bw0KCSBtYWtlDQoJIHRoaXMgd29yayBmb3Igc2Vydmxl
dCAyLjI/DQoJDQoJIFJlZ2FyZHMsDQoJDQoJIDwvcXVvdGU+DQoJDQoJDQoJIERhcnJlbiBEYXZp
c29uDQoJIENJQk0gSW50cmFuZXQgVGVhbQ0KCSBpbnQ+IDc5OSAxOTQzMQ0KCSBleHQ+ICs0NCAo
MCkyMCA3OTkxIDk0MzENCgkNCgkNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KCQ0KCVRoaXMgdHJhbnNtaXNzaW9uIGhhcyBiZWVuIGlzc3Vl
ZCBieSBhIG1lbWJlciBvZiB0aGUgSFNCQyBHcm91cA0KCSJIU0JDIiBmb3IgdGhlIGluZm9ybWF0
aW9uIG9mIHRoZSBhZGRyZXNzZWUgb25seSBhbmQgc2hvdWxkIG5vdCBiZQ0KCXJlcHJvZHVjZWQg
YW5kIC8gb3IgZGlzdHJpYnV0ZWQgdG8gYW55IG90aGVyIHBlcnNvbi4gRWFjaCBwYWdlIGF0dGFj
aGVkDQoJaGVyZXRvIG11c3QgYmUgcmVhZCBpbiBjb25qdW5jdGlvbiB3aXRoIGFueSBkaXNjbGFp
bWVyIHdoaWNoIGZvcm1zIHBhcnQNCglvZiBpdC4gVW5sZXNzIG90aGVyd2lzZSBzdGF0ZWQsIHRo
aXMgdHJhbnNtaXNzaW9uIGlzIG5laXRoZXIgYW4gb2ZmZXIgbm9yIHRoZQ0KCXNvbGljaXRhdGlv
biBvZiBhbiBvZmZlciB0byBzZWxsIG9yIHB1cmNoYXNlIGFueSBpbnZlc3RtZW50LiBJdHMgY29u
dGVudHMgYXJlDQoJYmFzZWQgb24gaW5mb3JtYXRpb24gb2J0YWluZWQgZnJvbSBzb3VyY2VzIGJl
bGlldmVkIHRvIGJlIHJlbGlhYmxlIGJ1dA0KCUhTQkMgbWFrZXMgbm8gcmVwcmVzZW50YXRpb24g
YW5kIGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgb3IgbGlhYmlsaXR5IGFzIHRvIGl0cyBjb21w
bGV0ZW5lc3Mgb3IgYWNjdXJhY3kuDQoJDQoJDQoNCg==

[Springframework-developer] TR : [springframework - Help] Spring JDBC object usage - multiple queries

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

-----Message d'origine-----
De=A0: JP Pawlak [mailto:jp....@ti...]=20
Envoy=E9=A0: lundi 11 ao=FBt 2003 19:51
=C0=A0: 'SourceForge.net'
Objet=A0: RE : [springframework - Help] Spring JDBC object usage -
multiple queries

Hi Jim,

This is a common situation. Rod was using a technique approaching this
done below. But in fact no of the two application demos uses it. In such
case, we generally create a first abstract class subclassing the mapRow
method which contains the common code and an incomplete constructor.
Something like this:

	abstract class MyObjectSqlQuery extends MappingSqlQuery{
       =20
		protected MyObjectSqlQuery (DataSource ds, String sql) {
			super(ds, sql);
			// No compile in this class
		}
=20
		protected Object mapRow(ResultSet rs, int rownum) throws
SQLException {
			MyObject myObject =3D ...
			// Here creating the object from the resultset
			// Assuming all the SQL orders calling for the
needed fields.
			return myObject;
		}
	}

And after all concrete Query objects will subclass it.

	class AllMyObjectSqlQuery extends MyObjectSqlQuery {
		protected AllMyObjectSqlQuery (DataSource ds) {
			super(ds, SQL_SELECT_ALL);
			compile();
		}
	}

	class SomeMyObjectSqlQuery extends MyObjectSqlQuery {
		protected SomeMyObjectSqlQuery (DataSource ds) {
			super(ds, SQL_SELECT_SOME);
			// Related to the WHERE statement
			declareParameter(new
SqlParameter(Types.INTEGER));
			declareParameter(new SqlParameter(Types.CHAR));
			declareParameter(new SqlParameter(Types.CHAR));
			...
			compile();
		}
	}

For these two classes you generally will use one of the execute()
methods or  add a method using them internally.

For a single retrieval :

	class FindMyObjectSqlQuery extends MyObjectSqlQuery {
		protected FindMyObjectSqlQuery (DataSource ds) {
			super(ds, SQL_SELECT_ONE);
			// Generally just the id as integer or long like
here
			declareParameter(new
SqlParameter(Types.BIGINT));
			compile();
		}
	=09
		public MyObject getMyObject(long id) {
			return (MyObject) this.findObject(id);
		}
	}

Nevertheless, you must have a specific class for each SQL Select with a
different parameters signature with this design. Otherwise, you will
make tricky SQL select for optional elements in the WHERE Clause [(name
=3D ? or isnull(?))].

Hope this answer to your question,
Regards,
Jean-Pierre

-----Message d'origine-----
De=A0: SourceForge.net [mailto:no...@so...]=20
Envoy=E9=A0: lundi 11 ao=FBt 2003 17:50
=C0=A0: no...@so...
Objet=A0: [springframework - Help] Spring JDBC object usage - multiple
queries


Read and respond to this message at:=20
https://sourceforge.net/forum/message.php?msg_id=3D2145145
By: jnemesh

Hi!  I'm exploring the Spring framework a bit, and I have a question:

I typically do 2 modes of queries for selects:
Find a single object
Range

So, for example, the API might allow for someone to find a single
datatype,
or a list of all available datatypes.

I'd like to bundle those 2 calls under the same object, so I can avoid
repetition
of code (for mapping the results.)  What I'd like to do is be able to
register
multiple sql querries for the object, and call the correct one via
methods with
strong typing that internally call execute(<params>).

One of the problems I'm running into with this is that different queries
on
the same object wind up having different parameters, and I can't
undeclare params
before I compile.  Because of this, if methods are run in the wrong
order it
causes problems.

If I were to subclass one of the classes so that the mapping code was
reused,
wouldn't I be exposing the other class's methods and causing this same
problem?

What's a good way to handle this?  Or should I just implement a new
class for
each query, and re-use the mapping code?  I guess I could implement a
super
class that just has the mapping code, and each subclass could extend it
- but
that leaves me with even more classes to deal with.  And the API for a
thousand
classes with 1 method each is difficult to read.

Any advice greatly appreciated.

-Jim

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:=20
https://sourceforge.net/forum/unmonitor.php?forum_id=3D250340

Re: [Springframework-developer] Re: [Springframework-user] applicationContext.xml for servlet 2.2

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

>Would there be any interest in reviving the skeleton of the 
old i21 servlet 
that used to do this, just for the sake of backwards 
compatibility - at 
least for a while?  I know it *is* a step backwards, but many 
large 
corporations do have a habit of moving reluctantly to newer 
versions of 
application servers and plenty may appreciate the gesture.  
Seems a shame 
to push this framework activity into the application domain 
when it's only 
a dozen lines of code and it looks to be the only thing 
preventing servlet 
2.2 compatibility for the MVC codebase. 

+1

[Springframework-developer] Re: [Springframework-user] applicationContext.xml for servlet 2.2

[<dar...@hs...>]

Would there be any interest in reviving the skeleton of the old i21 servlet
that used to do this, just for the sake of backwards compatibility - at
least for a while?  I know it *is* a step backwards, but many large
corporations do have a habit of moving reluctantly to newer versions of
application servers and plenty may appreciate the gesture.  Seems a shame
to push this framework activity into the application domain when it's only
a dozen lines of code and it looks to be the only thing preventing servlet
2.2 compatibility for the MVC codebase.

Attached is a modified version of the servlet with suitable @deprecated
tags and comments for consideration.  It should have no impact on any
existing code from 0.9.1

All the best,
Darren.

(See attached file: ContextLoaderServlet.java)

<quote>
Hi Darren,

You're right, Spring assumes Servlet 2.3 in that it recommends listeners
for startup work, like ContextLoaderListener and Log4jConfigListener. We
compile against Servlet 2.3, so there might be some other dependencies too,
but none that I can think of at the moment.

If you look at the implementation of ContextLoaderListener, you'll find
that it just delegates the contextInitialized event to
ContextLoader.initContext(event.getServletContext()). So in a Servlet 2.2
container, you could write your own load-on-startup servlet that invokes
ContextLoader.initContext in its init method, among other custom startup
work that you may require, like Log4J initialization.

Regards,
Juergen



 -----Urspr=FCngliche Nachricht-----
 Von: Darren Davison [mailto:da...@da...]
 Gesendet: So 10.08.2003 21:19
 An: spr...@li...
 Cc:
 Betreff: [Springframework-user] applicationContext.xml for servlet 2.2



 hi,

 All of the example web projects load the applicationContext with a

 <listener>
   <listener-class>
     com.interface21.web.context.ContextLoaderListener
   </listener-class>
 </listener>

 which is servlet 2.3 specific.  Is there a supported/recommended way to
 make
 this work for servlet 2.2?

 Regards,

 </quote>


 Darren Davison
 CIBM Intranet Team
 int> 799 19431
 ext> +44 (0)20 7991 9431


_____________________________________________________

This transmission has been issued by a member of the HSBC Group=20
"HSBC" for the information of the addressee only and should not be=20
reproduced and / or distributed to any other person. Each page attached=20
hereto must be read in conjunction with any disclaimer which forms part=20
of it. Unless otherwise stated, this transmission is neither an offer nor t=
he=20
solicitation of an offer to sell or purchase any investment. Its contents a=
re=20
based on information obtained from sources believed to be reliable but
HSBC makes no representation and accepts no responsibility or liability as=
 to its completeness or accuracy.

Fwd: Re: Re: [Springframework-developer] callback using RMI remoting

[Dongdong Z. <dz...@ur...>]

---- forwarded message attached ---


________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag

Re: [Springframework-developer] callback using RMI remoting

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

V2hhdCBleGFjdGx5IGRvIHlvdSBpbnRlbmQ/IFdoYXQga2luZCBvZiBjYWxsYmFjayBkbyB5b3Ug
bWVhbj8NCiANCkp1ZXJnZW4NCiANCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0
LS0tLS0gDQoJVm9uOiBEb25nZG9uZyBaaGFuZyBbbWFpbHRvOmR6aGFuZ0B1cmVhY2guY29tXSAN
CglHZXNlbmRldDogU28gMTAuMDguMjAwMyAxOTowMCANCglBbjogc3ByaW5nZnJhbWV3b3JrLWRl
dmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQoJQ2M6IA0KCUJldHJlZmY6IFtTcHJpbmdm
cmFtZXdvcmstZGV2ZWxvcGVyXSBjYWxsYmFjayB1c2luZyBSTUkgcmVtb3RpbmcNCgkNCgkNCg0K
CUhpDQoJDQoJaXMgaXQgcG9zc2libGUgdG8gZG8gY2FsbGJhY2sgdXNpbmcgdGhlIHJtaSByZW1v
dGluZyBwYWNrYWdlPw0KCWNhbiB5b3UgZ2l2ZSBtZSBhIHNpbXBsZSBleGFtcGxlPw0KCQ0KCVRo
YW5rcw0KCQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KCUdldCB5b3VyIG93biAiODAwIiBudW1iZXINCglWb2ljZW1haWwsIGZheCwgZW1haWwsIGFu
ZCBhIGxvdCBtb3JlDQoJaHR0cDovL3d3dy51cmVhY2guY29tL3JlZy90YWcNCgkNCgkNCgktLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJVGhp
cyBTRi5OZXQgZW1haWwgc3BvbnNvcmVkIGJ5OiBGcmVlIHByZS1idWlsdCBBU1AuTkVUIHNpdGVz
IGluY2x1ZGluZw0KCURhdGEgUmVwb3J0cywgRS1jb21tZXJjZSwgUG9ydGFscywgYW5kIEZvcnVt
cyBhcmUgYXZhaWxhYmxlIG5vdy4NCglEb3dubG9hZCB0b2RheSBhbmQgZW50ZXIgdG8gd2luIGFu
IFhCT1ggb3IgVmlzdWFsIFN0dWRpbyAuTkVULg0KCWh0dHA6Ly9hc3BuZXQuY2xpY2stdXJsLmNv
bS9nby9wc2EwMDEwMDAwM2F2ZS9kaXJlY3Q7YXQuYXNwbmV0XzA3MjMwM18wMS8wMQ0KCV9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJU3ByaW5nZnJhbWV3
b3JrLWRldmVsb3BlciBtYWlsaW5nIGxpc3QNCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxp
c3RzLnNvdXJjZWZvcmdlLm5ldA0KCWh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3Rz
L2xpc3RpbmZvL3NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXINCgkNCg0K

[Springframework-developer] callback using RMI remoting

[Dongdong Z. <dz...@ur...>]

Hi

is it possible to do callback using the rmi remoting package?
can you give me a simple example?

Thanks

________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag

Re: [Springframework-developer] Spring Framework 0.9.1 released

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

Um9kLCBUaG9tYXMsIGV2ZXJ5b25lLA0KIA0KR29vZCB0aW1pbmcgOy0pIFNlcmlvdXNseSwgdGhl
IGlzc3VlIGlzIG5vdCB0aGF0IHRoZXJlIGFyZSBzdGlsbCBjaGFuZ2VzIGNvbWluZyBidXQgdGhh
dCAwLjkuMSBnb3Qgb3V0IHRvbyBsYXRlIGZvciBteSB0YXN0ZS4NCiANCkFueXdheSwgd2UgY2Fu
IGFsc28gcmVsZWFzZSBhIDAuOS4yIHdpdGggYWxsIGNoYW5nZXMgdGhhdCB3aWxsIGhhdmUgY29t
ZSBpbiB0aGUgbWVhbnRpbWUsIHJpZ2h0IGJlZm9yZSB3ZSBkbyB0aGUgaW5pdGlhbCBpbXBvcnQg
b2YgYW4gb3JnLnNwcmluZ2ZyYW1ld29yayB2ZXJzaW9uIHRvIHRoZSBuZXcgbW9kdWxlLiBBcyB0
aGVyZSBpcyBhIGNoYW5nZWxvZyBub3csIGFuZCBubyBvYnZpb3VzIGVycm9ycyBpbiBKYXZhZG9j
IGFueW1vcmUgKEkgZGlkIHF1aXRlIHNvbWUgcG9saXNoaW5nIGluIHRoZSBsYXN0IGZldyBkYXlz
IGFuZCB0b2RheSksIHJlbGVhc2luZyBhIGZvbGxvdy11cCBkb2VzIG5vdCBjYXVzZSBub3Rld29y
dGh5IGVmZm9ydC4NCiANClNvIGxldCdzIGdldCBhbGwgdGhlIG1pbm9yIHN0dWZmIHRoYXQgYW55
Ym9keSdzIHdvcmtpbmcgb24gaW50byB0aGUgY3VycmVudCBDVlMgbW9kdWxlIGFzIHNvb24gYXMg
cG9zc2libGUuIEknZCBhbHNvIGxpa2UgdG8gZW5jb3VyYWdlIGV2ZXJ5Ym9keSB0byB1c2UgdGhl
IGN1cnJlbnQgMC45LjEgZm9yIG93biBhcHBzLCBhbmQgZ2l2ZSBmZWVkYmFjayBpZiB0aGVyZSBh
cmUgYW55IGlzc3Vlcy4gSSBkb24ndCBleHBlY3Qgc2hvd3N0b3BwZXJzLCBidXQgZXZlbiBhIG51
bWJlciBvZiBtaW5vciBidWdzIGxpa2UgdGhlIFJtaVNlcnZpY2VFeHBvcnRlciBvbmUgY2FuIG1h
a2UgZW5vdWdoIGNoYW5nZXMgZm9yIGEgZmluYWwgMC45LjIgaW4gdGhlIDAuOSBicmFuY2guDQog
DQpKdWVyZ2VuDQogDQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0K
CVZvbjogdHJpc2JlcmdAdHJpZGIuY29tIFttYWlsdG86dHJpc2JlcmdAdHJpZGIuY29tXSANCglH
ZXNlbmRldDogRnIgMDguMDguMjAwMyAyMjozMiANCglBbjogUm9kIEpvaG5zb24gDQoJQ2M6IGrD
vHJnZW4gaMO2bGxlciBbd2VyazNBVF07IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMu
c291cmNlZm9yZ2UubmV0IA0KCUJldHJlZmY6IFJlOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Bl
cl0gU3ByaW5nIEZyYW1ld29yayAwLjkuMSByZWxlYXNlZA0KCQ0KCQ0KDQoJSnVlcmdlbiwgUm9k
ICYgQWxsLA0KCQ0KCUkgaGF2ZSBwdXQgdXAgYSBub3RpY2UgYWJvdXQgdGhlIG5ldyByZWxlYXNl
IG9uIHRoZSB3ZWIgc2l0ZS4NCgkNCgk+IEknbSBqdXN0IGFib3V0IHRvIGNvbW1pdCBzb21lIGNo
YW5nZXMgdG8gQU9QIGluIHRoZSBvbGQgY29tLmludGVyZmFjZTIxDQoJPiB0cmVlLCBidXQgSSBz
dWdnZXN0IHdlIGRvIHRoZSBwYWNrYWdlIHN3aXRjaCBlYXJseSBuZXh0IHdlZWsuDQoJPg0KCQ0K
CUkgYWxzbyBoYXZlIHNvbWUgY2hhbmdlcyB0byB0aGF0IGRpZCBub3QgbWFrZSAwLjkuMS4gIEkg
anVzdCBjaGVja2VkIGluIGEgY2hhbmdlDQoJdG8gdGhlIFN0b3JlZFByb2NlZHVyZS9TcWxQYXJh
bWV0ZXIuICBJdCBub3cgc3VwcG9ydHMgcmV0dXJuaW5nIGEgVHlwZXMuQVJSQVkNCglmcm9tIGEg
c3RvcmVkIHByb2NlZHVyZSBiYXNlZCBvbiBhIHR5cGUgbmFtZSAtLSBvbmx5IHRlc3RlZCB3aXRo
IE9yYWNsZSBzbyBmYXIuDQoJIFRoaXMgaXMgYWxsIHN0YW5kYXJkIEpEQkMgZnVuY3Rpb25hbGl0
eSAtIG5vdGhpbmcgT3JhY2xlIHNwZWNpZmljLiANCgkNCglMZXQncyBhbGwgY29vcmRpbmF0ZSBi
ZWZvcmUgd2UgY3V0IG92ZXIgdG8gYSBuZXcgQ1ZTIG1vZHVsZSBzbyB3ZSBkb24ndCBoYXZlIHRv
DQoJcmVhcHBseSBjaGFuZ2VzIHRoYXQgbWlzc2VkIHRoZSBjdXRvdmVyLg0KCQ0KCVRob21hcw0K
CQ0KCQ0KCVAuUy4NCgkNCglZb3UgY291bGQgdXNlIHRoZXMgbmV3IGZlYXR1cmUgbGlrZSB0aGlz
Og0KCQ0KCUNSRUFURSBUWVBFIHRfYXJyYXkgSVMgVEFCTEUgT0YgVkFSQ0hBUjIoMTAwMCk7DQoJ
DQoJQ1JFQVRFIEZVTkNUSU9OIGdldF9hcnJheSBSRVRVUk4gdF9hcnJheQ0KCSAgIElTDQoJICAg
ICAgdl92YWx1ZXMgdF9hcnJheTsNCgkgICBCRUdJTg0KCSAgICAgIFNFTEVDVCBjb2wxIEJVTEsg
Q09MTEVDVCBJTlRPIHZfdmFsdWVzDQoJICAgICAgIEZST00gdGFibGUxOw0KCSAgICAgIFJFVFVS
TiB2X3ZhbHVlczsNCgkgICBFWENFUFRJT04NCgkgICAgICBXSEVOIE5PX0RBVEFfRk9VTkQgVEhF
Tg0KCSAgICAgICAgIFJFVFVSTiBOVUxMOw0KCSAgIEVORDsNCgkNCgkNCglwcml2YXRlIGNsYXNz
IE15Q2FsbCBleHRlbmRzIFN0b3JlZFByb2NlZHVyZSB7DQoJICAgICAgIA0KCSAgICBwdWJsaWMg
TXlDYWxsKERhdGFTb3VyY2UgZHMpIHsNCgkgICAgICAgIHN1cGVyKGRzLCAiZ2V0X2FycmF5Iik7
DQoJICAgICAgICBzZXRGdW5jdGlvbih0cnVlKTsNCgkgICAgICAgIGRlY2xhcmVQYXJhbWV0ZXIo
bmV3IE91dHB1dFBhcmFtZXRlcigiYXJyYXkiLCBUeXBlcy5BUlJBWSwgIlRfQVJSQVkiKSk7DQoJ
ICAgICAgICBjb21waWxlKCk7DQoJICAgIH0NCgkgICAgICAgDQoJICAgIHB1YmxpYyBTdHJpbmdb
XSBleGVjdXRlKCkgew0KCSAgICAgICAgTWFwIGluID0gbmV3IEhhc2hNYXAoKTsNCgkgICAgICAg
IE1hcCBvdXQgPSBleGVjdXRlKGluKTsNCgkgICAgICAgIGphdmEuc3FsLkFycmF5IHJldFZhbHVl
ID0gKGphdmEuc3FsLkFycmF5KSBvdXQuZ2V0KCJhcnJheSIpOw0KCSAgICAgICAgU3RyaW5nW10g
cmV0U3RyaW5nQXJyYXkgPSBudWxsOw0KCSAgICAgICAgdHJ5IHsNCgkgICAgICAgICAgICByZXRT
dHJpbmdBcnJheSA9IChTdHJpbmdbXSkgcmV0VmFsdWUuZ2V0QXJyYXkoKTsNCgkgICAgICAgIH0N
CgkgICAgICAgIGNhdGNoIChTUUxFeGNlcHRpb24gc2UpIHsNCgkgICAgICAgICAgIHRocm93IG5l
dyBUeXBlTWlzbWF0Y2hEYXRhQWNjZXNzRXhjZXB0aW9uKCJGYWlsZWQgdG8gZ2V0IGFycmF5Iiwg
c2UpOw0KCSAgICAgICAgfSAgICAgIA0KCSAgICAgICAgcmV0dXJuIHJldFN0cmluZ0FycmF5Ow0K
CSAgICB9DQoJDQoJfQ0KCQ0KCQ0KDQo=

Re: [Springframework-developer] Spring Framework 0.9.1 released

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

Juergen, Rod & All,

I have put up a notice about the new release on the web site.

> I'm just about to commit some changes to AOP in the old com.interface21
> tree, but I suggest we do the package switch early next week.
> 

I also have some changes to that did not make 0.9.1.  I just checked in a change
to the StoredProcedure/SqlParameter.  It now supports returning a Types.ARRAY
from a stored procedure based on a type name -- only tested with Oracle so far.
 This is all standard JDBC functionality - nothing Oracle specific.  

Let's all coordinate before we cut over to a new CVS module so we don't have to
reapply changes that missed the cutover.

Thomas


P.S.

You could use thes new feature like this:

CREATE TYPE t_array IS TABLE OF VARCHAR2(1000);

CREATE FUNCTION get_array RETURN t_array
   IS
      v_values t_array;
   BEGIN
      SELECT col1 BULK COLLECT INTO v_values
       FROM table1;
      RETURN v_values;
   EXCEPTION
      WHEN NO_DATA_FOUND THEN
         RETURN NULL;
   END;


private class MyCall extends StoredProcedure {
	
    public MyCall(DataSource ds) {
        super(ds, "get_array");
        setFunction(true);
        declareParameter(new OutputParameter("array", Types.ARRAY, "T_ARRAY"));
        compile();
    }
	
    public String[] execute() {
        Map in = new HashMap();
        Map out = execute(in);
        java.sql.Array retValue = (java.sql.Array) out.get("array");
        String[] retStringArray = null;
        try {
            retStringArray = (String[]) retValue.getArray();
        }
        catch (SQLException se) {
           throw new TypeMismatchDataAccessException("Failed to get array", se);
        }	
        return retStringArray;
    }

}

Re: [Springframework-developer] RmiServiceExporter Bug?

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

VGhhbmtzIGZvciB0aGUgcmVwb3J0IC0gdGhpcyBpcyBpbmRlZWQgYSBicm9rZW4gY2hlY2suIFRo
ZSBjdXJyZW50IFJtaVNlcnZpY2VFeHBvcnRlciB3aWxsIGp1c3Qgd29yayB3aXRoIGFuIGFscmVh
ZHkgcnVubmluZyBSTUkgcmVnaXN0cnksIGUuZy4gYSBzdGFydGVkIHJtaXJlZ2lzdHJ5LmV4ZS4g
Tm90ZSB0aGF0IHN1Y2ggYSByZWdpc3RyeSBuZWVkcyB0byBoYXZlIHRoZSBSZW1vdGVJbnZvY2F0
aW9uV3JhcHBlciBzdHViIGluIHRoZSBjbGFzc3BhdGgsIGkuZS4gYSBzcHJpbmctZnVsbCBqYXIu
DQogDQpJIGNvbnNpZGVyIHRoZSByZWdpc3RyeSBjaGVjayBhIGJpdCBvZiBhIGhhY2ssIGZyYW5r
bHksIGFzIGFuIFJNSSByZWdpc3RyeSBzaG91bGQgYmUgc3RhcnRlZCBpbiBhIG1vcmUgY29udHJv
bGxlZCB3YXkgYW55d2F5ICh0aGF0J3Mgd2h5IHRoZSAiY291bGRuJ3QgZmluZCByZWdpc3RyeSAt
IGNyZWF0aW5nIG5ldyBvbmUiIGxvZyBpcyBhdCAqd2FybiogbGV2ZWwpLiBOZXZlcnRoZWxlc3Ms
IEkndmUganVzdCBhZGRlZCBhICJsaXN0IiBjYWxsIHRvIHRoZSByZWdpc3RyeSBjaGVjaywgYWxy
ZWFkeSBjb21taXR0ZWQgdG8gQ1ZTLg0KIA0KSnVlcmdlbg0KIA0KIA0KDQoJLS0tLS1VcnNwcsO8
bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IERvbmdkb25nIFpoYW5nIFttYWlsdG86ZHpo
YW5nQHVyZWFjaC5jb21dIA0KCUdlc2VuZGV0OiBGciAwOC4wOC4yMDAzIDIwOjE0IA0KCUFuOiBz
cHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCANCglDYzogDQoJ
QmV0cmVmZjogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIFJtaVNlcnZpY2VFeHBvcnRlciBC
dWc/DQoJDQoJDQoNCglIaQ0KCQ0KCUkgYW0gdHJ5aW5nIHRvIHVzZSB0aGUgdHJhbnNwYXJlbnQg
Uk1JIHBhY2thZ2UsIGFuZCBmb3VuZCBhDQoJcHJvYmxlbSB3aXRoIFJtaVNlcnZpY2VFeHBvcnRl
ci4NCgkNCglJbiBhZnRlclByb3BlcnRpZXNTZXQgbWV0aG9kLA0KCUxvY2F0ZVJlZ2lzdHJ5Lmdl
dFJlZ2lzdHJ5KHRoaXMucG9ydCkgaXMgdXNlZCB0byBkZXRlY3QgaWYgdGhlDQoJcmVnaXN0cnkg
aXMgcnVubmluZyBvciBub3QsIGJ1dCBnZXRSZWdpc3RyeSBkb2VzIG5vdCB0aHJvdw0KCVJlbW90
ZUV4Y2VwdGlvbiBpZiBubyByZWdpc3RyeSBydW5uaW5nLCBoZXJlIGlzIGEgcXVvdGUgZnJvbQ0K
CWphdmFkb2MgZm9yIExvY2F0ZVJlZ2lzdHJ5DQoJDQoJIk5vdGUgdGhhdCBhIGdldFJlZ2lzdHJ5
IGNhbGwgZG9lcyBub3QgYWN0dWFsbHkgbWFrZSBhDQoJY29ubmVjdGlvbiB0byB0aGUgcmVtb3Rl
IGhvc3QuIEl0IHNpbXBseSBjcmVhdGVzIGEgbG9jYWwNCglyZWZlcmVuY2UgdG8gdGhlIHJlbW90
ZSByZWdpc3RyeSBhbmQgd2lsbCBzdWNjZWVkIGV2ZW4gaWYgbm8NCglyZWdpc3RyeSBpcyBydW5u
aW5nIG9uIHRoZSByZW1vdGUgaG9zdC4gVGhlcmVmb3JlLCBhIHN1YnNlcXVlbnQNCgltZXRob2Qg
aW52b2NhdGlvbiB0byBhIHJlbW90ZSByZWdpc3RyeSByZXR1cm5lZCBhcyBhIHJlc3VsdCBvZg0K
CXRoaXMgbWV0aG9kIG1heSBmYWlsIg0KCQ0KCXNvIGV2ZW4gaWYgbm8gcmVnaXN0cnkgcnVubmlu
ZywgZ2V0UmVnaXN0cnkgd2lsbCByZXR1cm4gc29tZQ0KCXZhbHVlLCBhbmQgc3Vic2VxdWVudCBy
ZWJpbmQgd2lsbCBmYWlsLg0KCQ0KCWlmIHdlIGNhbGwgbGlzdCBtZXRob2Qgb24gdGhlIHJlZ2lz
dHJ5IHJldHVybmVkIGJ5IGdldFJlZ2lzdHJ5LA0KCWl0IHdpbGwgdGhyb3cgUmVtb3RlRXhjZXB0
aW9uIGlmIG5vIHJlZ2lzdHJ5IHJ1bm5pbmcuDQoJDQoJUmVnYXJkcw0KCQ0KCQ0KCQ0KCV9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCUdldCB5b3VyIG93
biAiODAwIiBudW1iZXINCglWb2ljZW1haWwsIGZheCwgZW1haWwsIGFuZCBhIGxvdCBtb3JlDQoJ
aHR0cDovL3d3dy51cmVhY2guY29tL3JlZy90YWcNCgkNCgkNCgktLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJVGhpcyBTRi5OZXQgZW1haWwg
c3BvbnNvcmVkIGJ5OiBGcmVlIHByZS1idWlsdCBBU1AuTkVUIHNpdGVzIGluY2x1ZGluZw0KCURh
dGEgUmVwb3J0cywgRS1jb21tZXJjZSwgUG9ydGFscywgYW5kIEZvcnVtcyBhcmUgYXZhaWxhYmxl
IG5vdy4NCglEb3dubG9hZCB0b2RheSBhbmQgZW50ZXIgdG8gd2luIGFuIFhCT1ggb3IgVmlzdWFs
IFN0dWRpbyAuTkVULg0KCWh0dHA6Ly9hc3BuZXQuY2xpY2stdXJsLmNvbS9nby9wc2EwMDEwMDAw
M2F2ZS9kaXJlY3Q7YXQuYXNwbmV0XzA3MjMwM18wMS8wMQ0KCV9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBt
YWlsaW5nIGxpc3QNCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdl
Lm5ldA0KCWh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3Nwcmlu
Z2ZyYW1ld29yay1kZXZlbG9wZXINCgkNCg0K

[Springframework-developer] Additional packages

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

Guys,

I've been doing some profiling for work and using the load testing package I
published with the book. (I actually improved it in December.)

It's obviously not something that is a key part of Spring, but it's worth
having outside the src directory, because it is a whole lot simpler and
easier to configure than Grinder and JMeter. (Of course it's configured
using JavaBeans--what else!)

It's also useful for some critical performance benchmarks for Spring. We can
run these to ensure that changes don't reduce performance significantly.

Things such as:

- AOP functionality (I've got a test for this already)
- BeanFactory functionality
- JDBC (not sure how to test)

Of course performance testing isn't an exact science, but it could still be
useful.

So I'm planning to check in the load tester and critical performance tests
in a /load tree in the main module. Any better ideas?

Also, what's the feeling on new module? I'm inclined to favour it. I've just
made some changes to AOP in the old module.

Regards,
Rod

[Springframework-developer] RmiServiceExporter Bug?

[Dongdong Z. <dz...@ur...>]

Hi

I am trying to use the transparent RMI package, and found a
problem with RmiServiceExporter.

In afterPropertiesSet method,
LocateRegistry.getRegistry(this.port) is used to detect if the
registry is running or not, but getRegistry does not throw
RemoteException if no registry running, here is a quote from
javadoc for LocateRegistry

"Note that a getRegistry call does not actually make a
connection to the remote host. It simply creates a local
reference to the remote registry and will succeed even if no
registry is running on the remote host. Therefore, a subsequent
method invocation to a remote registry returned as a result of
this method may fail"

so even if no registry running, getRegistry will return some
value, and subsequent rebind will fail. 

if we call list method on the registry returned by getRegistry,
it will throw RemoteException if no registry running.

Regards



________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag

Re: [Springframework-developer] Spring Framework 0.9.1 released

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

Again, Juergen, thanks for the hard work on the release!

I'm just about to commit some changes to AOP in the old com.interface21
tree, but I suggest we do the package switch early next week.

Regards,
Rod

----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>;
<spr...@li...>
Sent: Friday, August 08, 2003 5:22 PM
Subject: [Springframework-developer] Spring Framework 0.9.1 released


Hi everybody,

We've just released Spring Framework 0.9.1. The SourceForge download page
provides a detailed changelog.

I encourage all 0.9 users to switch to 0.9.1, as it offers significant new
features and includes a number of important bugfixes.

This release still uses com.interface21 as package name. It can be
considered a drop-in replacement for 0.9, with very few incompatible changes
but numerous improved features.

1.0 M1 (to be released end of August) will introduce the new
org.springframework package name, with few new features but revised
documentation etc.

Regards,
Juergen


DI Jürgen Höller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

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



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

[Springframework-developer] Spring Framework 0.9.1 released

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

Hi everybody,

We've just released Spring Framework 0.9.1. The SourceForge download =
page provides a detailed changelog.

I encourage all 0.9 users to switch to 0.9.1, as it offers significant =
new features and includes a number of important bugfixes.

This release still uses com.interface21 as package name. It can be =
considered a drop-in replacement for 0.9, with very few incompatible =
changes but numerous improved features.

1.0 M1 (to be released end of August) will introduce the new =
org.springframework package name, with few new features but revised =
documentation etc.

Regards,
Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

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

Re: [Springframework-developer] PicoContainer

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

Some interesting links with reaction to our PicoContainer 
comparison:

http://lists.codehaus.org/pipermail/picocontainer-dev/2003-
July/000458.html

http://jira.codehaus.org/secure/ViewIssue.jspa?key=PICO-18

http://www.mail-archive.com/opensymphony-
we...@li.../msg03275.html

The PicoContainer guys think that Spring should become a 
NanoContainer, and it sounds like they're jumping onto the 
JavaBeans bandwagon. Rather amusing, since Spring has been 
around for 6 months and my book, which outlined the design, 
has been out for the best part of a year. They could have 
joined us :-)

Shows we should keep up the PR effort, and that it's 
important to be fair and reasonable in comparisons. I think 
it's helped a lot that we don't sound bigoted and that we 
don't attempt to dismiss Struts/PicoContainer etc without a 
fair comparison.

Regards,
Rod

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

[Timo V. <sic...@gm...>]

> I don't thinks there's a problem: As I said, equals() is still id
> based, only hashCode() is "created" based. And its no problem that
> differerent (according to equals()) instances have the same
> hashCode(). It perfectly holds the contract! The database just should
> not truncate any bits! Otherwise there will be problems, of course.

One more thing: Basically you could base the hashCode on any 
UNMODIFIEABLE  random value, as long as its initialized on object 
construction. BUT the creation time is a good thing for me, since I 
store/use it anyway.

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

[Timo V. <sic...@gm...>]

Hi!


> You may run into problems with that solution.  Depending upon the
> precision of how the data is stored in your database, you may have a
> wide window where multiple objects have the same date.
>
> Let's just say, for sake of arguement, that your database only holds
> date to the nearest second, and loses any sub-second accuracy.  If
> two objects are created within the same second in your app, and then
> stored to the DB, when they are pulled back they will have the same
> created time, and thus your code will think they are the same object.

I don't thinks there's a problem: As I said, equals() is still id based, 
only hashCode() is "created" based. And its no problem that differerent 
(according to equals()) instances have the same hashCode(). It 
perfectly holds the contract! The database just should not truncate any 
bits! Otherwise there will be problems, of course.

> If you want a better solution for this scheme of generating a
> hashcode, use a GUID / UUID generator.  These take time / machine
> (usually IP address in Java, network card MAC address in C.) and
> usually other "unique/random" parameters into account for creating an
> ID.  Using a good GUID / UUID generator with a good algorithm will
> GUARANTEE that no two id's are the same, without the need for any
> synchronization between machines (like hi/low, sequence, etc
> require).  Since Java based GUID / UUID generators generally use the
> machines IP address as part of the algorithm, you need to be sure
> that the IP address of each machine is unique.  This is usually not a
> problem in a lan / lan cluster environment.  Also make sure your
> algorithm doesn't mistakenly use 127.0.0.1 as it's IP address, as all
> machines have that IP.
I don't want to use GUIDs in some cases. I sometimes HAVE to use 
database native sequences/autovalues. 


Regards,

Timo

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

[Rob B. <rob...@ve...>]

Timo,

You may run into problems with that solution.  Depending upon the precision of how the data is stored in your database, you may have a wide window where multiple objects have the same date.

Let's just say, for sake of arguement, that your database only holds date to the nearest second, and loses any sub-second accuracy.  If two objects are created within the same second in your app, and then stored to the DB, when they are pulled back they will have the same created time, and thus your code will think they are the same object.

If you want a better solution for this scheme of generating a hashcode, use a GUID / UUID generator.  These take time / machine (usually IP address in Java, network card MAC address in C.) and usually other "unique/random" parameters into account for creating an ID.  Using a good GUID / UUID generator with a good algorithm will GUARANTEE that no two id's are the same, without the need for any synchronization between machines (like hi/low, sequence, etc require).  Since Java based GUID / UUID generators generally use the machines IP address as part of the algorithm, you need to be sure that the IP address of each machine is unique.  This is usually not a problem in a lan / lan cluster environment.  Also make sure your algorithm doesn't mistakenly use 127.0.0.1 as it's IP address, as all machines have that IP.

Hope this helps out.

Later
Rob
> 
> 
> Hi all!
> 
> I think I finally have a solution to the hashCode/equals problems!
> 
> In every table I have a field/property named "created" of type datetime, 
> which may not be null. My domain objects hence all have a "created" 
> property, which is initialized with the current time on instantiation 
> ("new java.util.Date()"). Other applications using the database 
> directly MUST supply values for "created" (be they bogus or not). 
> "created" may not be altered once set, which could even be enforced 
> with the use of triggers/permissions on the DB side and a private 
> setCreated() method on the Java side. 
> 
> Now I "calculate" hashCode() based on the "created" property (invoke 
> getCreated().hashCode()) and equals() still based on ID. 
> 
> This should solve all problems issued before! 
> 
> Opinions? Have I missed anything?
> 
> 
> Regards,
> 
> Timo

[Springframework-developer] Changelog

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

Quick 0.9.1 preview: If anyone has immediate comments on the changelog, =
please give feedback within the next 2 hours :-)

Juergen


SPRING FRAMEWORK CHANGELOG
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

Changes in version 0.9.1 (8.8.2003)
-----------------------------------
* fixed error logging in XmlBeanFactory
* support for XML bean definition includes via XML entities
* new BeanFactoryPostProcessor hook to override bean definition values
* revised PropertyResourceConfigurer based on BeanFactoryPostProcessor
* support for execution context in SqlQuery hierarchy
* eager initialization of exception translator in JdbcTemplate
* fixed StoredProcedure transaction participation
* revised simple JNDI implementation
* revised JDO LocalPersistenceManagerFactoryBean with support for =
bean-defined settings
* revised Hibernate LocalSessionFactoryBean with support for =
bean-defined settings
* ability to use Spring-configured DataSource for Hibernate
* support for Hibernate entity interceptors
* new HibernateTemplate convenience methods for single-step actions
* fixed Hibernate transaction exception logging
* support for read-only transactions
* revised TransactionInterceptor configuration options
* TransactionInterceptor does not have a default strategy anymore
* updated AOP framework to current AOP Alliance interfaces
* optional CGLIB support in the AOP framework (to proxy full classes)
* distinction between static and dynamic method pointcuts
* new regular expression pointcut
* revised EJB support classes with BeanFactory access
* support for Ant-style path matching in the web framework
* revised VelocityConfigurer with support for bean-defined settings
* new BindInitializer support in BindUtils
* support for JSP expression language in tag implementations
* recommended "<spring:" as tag prefix instead of "<i21:"
* turned sample "PagedList" into full-fledged "Countries"
* new Petclinic tutorial
* new MVC-step-by-step tutorial
* new article "The Spring Framework - A Lightweight Container"
* new article "Container Resources vs Local Resources"

Changes in version 0.9 (26.6.2003)
----------------------------------
* first public release since the version that came with the book "Expert =
One-on-One J2EE Design and Development"
* following various inofficial 0.8 CVS snapshots
* general tightening and polishing
* log via Commons Logging
* Log4J configuration support
* revised bean definition XML format with DTD
* support for lists, maps, and props in XML bean definitions
* support for hierarchical bean factories
* support for custom property editors
* various new out-of-the-box editors for dates, numbers, etc
* new FactoryBean interface instead of custom bean definitions
* FactoryBean-based resource definitions for JDBC DataSource etc
* revised simple DataSource implementations
* new JDBC error code exception translater
* new DataFieldMaxValueIncrementer support for JDBC
* new generic transaction management
* new JDO support: resource definition, transaction strategy, template, =
interceptor
* new Hibernate support: resource definition, transaction strategy, =
template, interceptor
* new support for remoting via Hessian and Burlap
* new AOP framework aligned with AOP Alliance
* revised EJB access classes based on AOP
* resource access from application contexts
* support for MessageSourceResolvable
* revised validation framework
* support for global validation errors
* revised web framework
* refactored form controller hierarchy
* new handler interception mechanism
* locale and theme resolution
* support for HTML escaping
* revised JSP tag implementations
* new sample application "Petclinic"
* new sample application "PagedList"
* application skeletons as configuration showcases
* (many new convenience classes and methods)
* (too many minor improvements to list)
* (lots of minor bugfixes)


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

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

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

[Timo V. <sic...@gm...>]

Hi all!

I think I finally have a solution to the hashCode/equals problems!

In every table I have a field/property named "created" of type datetime, 
which may not be null. My domain objects hence all have a "created" 
property, which is initialized with the current time on instantiation 
("new java.util.Date()"). Other applications using the database 
directly MUST supply values for "created" (be they bogus or not). 
"created" may not be altered once set, which could even be enforced 
with the use of triggers/permissions on the DB side and a private 
setCreated() method on the Java side. 

Now I "calculate" hashCode() based on the "created" property (invoke 
getCreated().hashCode()) and equals() still based on ID. 

This should solve all problems issued before! 

Opinions? Have I missed anything?


Regards,

Timo

Re: [Springframework-developer] Parser problems in com.interface21.web.context tests

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

I'm getting this in Eclipse also and getting the same problem with Crimson.
Seems to be due to Juergen's new include functionality.

Regards,
Rod

----- Original Message -----
From: "Luke Taylor" <ne...@fr...>
To: <spr...@li...>
Sent: Thursday, August 07, 2003 4:29 PM
Subject: [Springframework-developer] Parser problems in
com.interface21.web.context tests


> Hi,
>
> I've just updated the Maven stuff
>
> http://monkeymachine.ath.cx/spring/maven-reports.html
>
> and am seeing some errors in this package which aren't there with the
> normal test run.
>
> e.g.  Exception in constructor: testCount
> (org.xml.sax.SAXParseException: Relative URI
> "com/interface21/web/context/WEB-INF/contextInclude.xml"; can not be
> resolved without a base URI.
>
>
http://monkeymachine.ath.cx/spring/junit-report.html#ResourceBundleMessageSo
urceTestSuite
>
> The exception is thrown from here:
>
>
http://monkeymachine.ath.cx/spring/xref/com/interface21/beans/factory/xml/Xm
lBeanFactory.html#228
>
> I think ant is using xerces, whereas Maven is using crimson from the JDK
> (I'm using 1.4.1_03). If so then it might be an idea to tidy up the
> tests to be compatible with both parsers. I suppose there could
> potentially be implementation problems too.
>
> Luke.
>
>
> --
>   Luke Taylor.                      Monkey Machine Ltd.
>   PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>