springframework-developer — Spring Framework developers list

Re: [Springframework-developer] location of sql-error-codes.xml

[Tony F. <ton...@ya...>]

Fine by me.
 
 jürgen_höller_[werk3AT] <jue...@we...> wrote:Would anyone mind if we moved sql-error-codes.xml to src/com/interface21/jdbc/core? The root of the src tree is not a good location for it. Of course, the build script can still copy it from there to the root of any classes directory.

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
f. +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG


-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC.
Does your code think in ink? You could win a Tablet PC.
Get a free Tablet PC hat just for playing. What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Problems at Wrox

[Tim M. <mu...@on...>]

Rod,

What impact does Wrox's demise have on you and the book? I'd hate to 
see it lost as a resource and I'd hate to think you received no benefit 
from the half-dozen or so copies of the book my company has purchased.

--Tim

[Springframework-developer] JavaDoc style

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

Currently, Spring's method JavaDoc descriptions are mostly imperative, =
i.e. "Set the name", "Return the state". The Java code conventions =
suggest a descriptive style, i.e. "Sets the name", "Returns the state". =
Personally, I am used to the latter, and I repeatedly stumble upon mixed =
style in some Spring classes. It may be a minor issue, but we should =
still settle on a standard style.

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
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG

[Springframework-developer] location of sql-error-codes.xml

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

Would anyone mind if we moved sql-error-codes.xml to =
src/com/interface21/jdbc/core? The root of the src tree is not a good =
location for it. Of course, the build script can still copy it from =
there to the root of any classes directory.

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
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG

Re: [Springframework-developer] Update

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

I should note that I've reworked JndiServices a bit, else the contrast =
to JdbcTemplate is not obvious.

There was half-baked support for a pluggable ContextFactory in =
JndiServcies that de facto was not used. IMHO, a major advantage of JNDI =
is its universal lookup mechanism, just "new InitialContext()" and =
you're there. A pluggable ContextFactory makes this significantly =
harder, and I'm not sure about the benefits. Any JNDI implementation =
should be configurable so that "new InitialContext()" retrieves a =
correct context in any case.

Thus, I've removed ContextFactory support and reworked JndiServices into =
a static helper class, featuring the same methods as static versions. =
"DataSourceUtils.getDataSourceFromJndi" did not use JndiServices =
previously but does so now (and I've renamed it, it was =
"getDataSourceFromJNDI" before). BTW, I've added a new alternative =
constructor to JdbcTemplate, taking a data source name and resolving it =
via DataSourceUtils.

I haven't committed these changes yet, but I will soon if noone objects. =
This is completely independent of the JTA stuff, of course. Two more =
independent changes that I haven't checked in yet are the moved mock =
objects and the reworked MessageSourceResolvable stuff. I guess I will =
commit everything tomorrow, including my preliminary JTA support if Rod =
likes me to.

Juergen


-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT]=20
Sent: Thursday, March 20, 2003 9:50 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Update


Hi Rod,

Regarding AOP and transaction management: I'm really eager to look at =
that stuff. I'm currently trying to settle on a transaction handling way =
for our applications here at werk3AT, and this isn't as straightforward =
as it should be.

Interestingly, I've come up with something very similar to a thing your =
proposed: A com.interface21.jta package providing a JtaServices class =
and an associated TransactionCallback, among other things caring for the =
exception handling and transforming those awkward, loose JTA exceptions =
to the exception hierarchy in com.interface21.dao. We seem to duplicate =
effort here, so I guess we should try to synchronize. There's not much =
code involved, so I don't think that there has been much overhead yet.

Some sample application code using my current version:

public static void executeTransaction() {
	JtaServices.execute(
		new TransactionCallback() {
			public void doInTransaction() {
				executeTestUpdate();
				executeTestQuery();
			}
		}
	);
}

Obvious issues are:

- I use a JtaServices static helper class analogous to JndiServices =
rather than a JtaTemplate instance analogous to JdbcTemplate. The reason =
is that there's not much state involved currently: A thread only has one =
associated JTA UserTransaction, just like it only has one associated =
JNDI InitialContext - in constrast to potentially multiple JDBC =
DataSources. Does your implementation have more state that justifies =
using an instance, possibly configuration or potential subclassing?

- Instead of a new exception hierarchy in com.interface21.transaction, I =
chose to integrate the transaction exceptions into com.interface21.dao. =
The rationale behind this is that transactions are an inherent aspect of =
data access. Currently, I have only one new exception, namely =
DataAccessTransactionRollbackException. Other exceptions like JTA's =
SystemException get converted to the existing =
DataAccessResourceFailureException. The existing =
DeadlockLoserDataAccessException is now a subclass of =
DataAccessTransactionRollbackException.

- TransactionCallback.doInTransaction() does not throw any checked =
exceptions. Instead, any RuntimeException thrown causes the transaction =
to roll back (resp. a warning written to the log that the transaction =
should have been rolled back, when JTA isn't available), and gets =
rethrown to the caller. AOP allows for much more flexibility in this =
respect, but I don't see a more flexible way for the callback approach.

- A special characteristic of my version is that it allows for working =
without JTA as a fallback. If there's a problem retrieving the =
UserTransaction from JNDI and applying it, a warning gets written to the =
log, and the transactional application code gets executed without a =
transaction, using autocommit=3Dtrue. We currently use this for test =
suites that run in a plain VM with just a JNDI DataSource mock. It is =
also meant for being able to run your application in a non-JTA =
environment too (e.g. for a development or demo environment), while =
benefiting from JTA when available. BTW, an overloaded version of =
JtaServices.execute disables this fallback and enforces JTA =
availability.

- My current stuff may not be too sophisticated, but it works and I =
consider it beta quality. I have tested it with Tomcat 4.0/4.1 (both =
with and without Tyrex 0.9.7/1.0) and Resin 2.1, using Driver-backed =
"enabled" DataSources and real XADataSources. A version of Spring's JTA =
stuff can and should definitely make it for 0.9, as I consider =
transaction handling a very important issue.

- Note that at werk3AT, we don't need any distributed transactions yet: =
We simply use JTA for convenient transaction demarcation in high-level =
services. The underlying lower-level data access services use either =
JDBC via a JNDI datasource or the O/R mapping toolkit Hibernate (with a =
JNDI datasource underneath). This works nicely if the JNDI datasource is =
XA-capable, and allows for clear separation of concerns. Of course, =
one-phase commit is enough for this, so I don't mind "enabled" =
DataSources that are not truly XA-capable (like MySQL's). An obvious =
benefit of still basing our applications' transaction handling on JTA is =
that extending them to more datasources is very smooth.

- I've recently reviewed Hibernate's JTA usage in detail, i.e. in its =
source code. It's very straightforward, the only major issue is managing =
cache state. Hibernate needs to register a synchronization with the =
container's transaction manager, to be able to update the cache on =
transaction commit or rollback accordingly. Unfortunately, the JNDI =
location of the transaction manager is unspecified in J2EE, so Hibernate =
has a lookup interface and implementations for various application =
serves. In the current Hibernate version, this only works with explicit =
transaction handling in the data access code, and configuring Hibernate =
for JTA. Hibernate transactions then simply take part in existing JTA =
transactions, or start new ones if necessary. In the autocommit case, =
Hibernate cannot guarantee correct cache state, as there's no JTA =
synchronization then. This will be addressed by a JCA adapter in =
Hibernate 2.1.

- Finally, regarding PlatformTransactionManager: What functionality does =
this interface address in detail? Do we need to synchronize anything? =
Any concrete use cases?

So, how should we proceed? I could check in my current stuff, so that =
you can review it and merge it with your version. Of course, we can =
proceed the other way round too. What do you prefer?

Regards,
Juergen


P.S.:
Orion 2.0 has just been released. Hurray, it isn't dead! ;-) Seriously, =
I will definitely look at it soon. Hopefully, the web stuff is fully =
Servlet 2.3 compliant now.

RE: [Springframework-developer] Update

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

Hi Rod,

Regarding AOP and transaction management: I'm really eager to look at =
that stuff. I'm currently trying to settle on a transaction handling way =
for our applications here at werk3AT, and this isn't as straightforward =
as it should be.

Interestingly, I've come up with something very similar to a thing your =
proposed: A com.interface21.jta package providing a JtaServices class =
and an associated TransactionCallback, among other things caring for the =
exception handling and transforming those awkward, loose JTA exceptions =
to the exception hierarchy in com.interface21.dao. We seem to duplicate =
effort here, so I guess we should try to synchronize. There's not much =
code involved, so I don't think that there has been much overhead yet.

Some sample application code using my current version:

public static void executeTransaction() {
	JtaServices.execute(
		new TransactionCallback() {
			public void doInTransaction() {
				executeTestUpdate();
				executeTestQuery();
			}
		}
	);
}

Obvious issues are:

- I use a JtaServices static helper class analogous to JndiServices =
rather than a JtaTemplate instance analogous to JdbcTemplate. The reason =
is that there's not much state involved currently: A thread only has one =
associated JTA UserTransaction, just like it only has one associated =
JNDI InitialContext - in constrast to potentially multiple JDBC =
DataSources. Does your implementation have more state that justifies =
using an instance, possibly configuration or potential subclassing?

- Instead of a new exception hierarchy in com.interface21.transaction, I =
chose to integrate the transaction exceptions into com.interface21.dao. =
The rationale behind this is that transactions are an inherent aspect of =
data access. Currently, I have only one new exception, namely =
DataAccessTransactionRollbackException. Other exceptions like JTA's =
SystemException get converted to the existing =
DataAccessResourceFailureException. The existing =
DeadlockLoserDataAccessException is now a subclass of =
DataAccessTransactionRollbackException.

- TransactionCallback.doInTransaction() does not throw any checked =
exceptions. Instead, any RuntimeException thrown causes the transaction =
to roll back (resp. a warning written to the log that the transaction =
should have been rolled back, when JTA isn't available), and gets =
rethrown to the caller. AOP allows for much more flexibility in this =
respect, but I don't see a more flexible way for the callback approach.

- A special characteristic of my version is that it allows for working =
without JTA as a fallback. If there's a problem retrieving the =
UserTransaction from JNDI and applying it, a warning gets written to the =
log, and the transactional application code gets executed without a =
transaction, using autocommit=3Dtrue. We currently use this for test =
suites that run in a plain VM with just a JNDI DataSource mock. It is =
also meant for being able to run your application in a non-JTA =
environment too (e.g. for a development or demo environment), while =
benefiting from JTA when available. BTW, an overloaded version of =
JtaServices.execute disables this fallback and enforces JTA =
availability.

- My current stuff may not be too sophisticated, but it works and I =
consider it beta quality. I have tested it with Tomcat 4.0/4.1 (both =
with and without Tyrex 0.9.7/1.0) and Resin 2.1, using Driver-backed =
"enabled" DataSources and real XADataSources. A version of Spring's JTA =
stuff can and should definitely make it for 0.9, as I consider =
transaction handling a very important issue.

- Note that at werk3AT, we don't need any distributed transactions yet: =
We simply use JTA for convenient transaction demarcation in high-level =
services. The underlying lower-level data access services use either =
JDBC via a JNDI datasource or the O/R mapping toolkit Hibernate (with a =
JNDI datasource underneath). This works nicely if the JNDI datasource is =
XA-capable, and allows for clear separation of concerns. Of course, =
one-phase commit is enough for this, so I don't mind "enabled" =
DataSources that are not truly XA-capable (like MySQL's). An obvious =
benefit of still basing our applications' transaction handling on JTA is =
that extending them to more datasources is very smooth.

- I've recently reviewed Hibernate's JTA usage in detail, i.e. in its =
source code. It's very straightforward, the only major issue is managing =
cache state. Hibernate needs to register a synchronization with the =
container's transaction manager, to be able to update the cache on =
transaction commit or rollback accordingly. Unfortunately, the JNDI =
location of the transaction manager is unspecified in J2EE, so Hibernate =
has a lookup interface and implementations for various application =
serves. In the current Hibernate version, this only works with explicit =
transaction handling in the data access code, and configuring Hibernate =
for JTA. Hibernate transactions then simply take part in existing JTA =
transactions, or start new ones if necessary. In the autocommit case, =
Hibernate cannot guarantee correct cache state, as there's no JTA =
synchronization then. This will be addressed by a JCA adapter in =
Hibernate 2.1.

- Finally, regarding PlatformTransactionManager: What functionality does =
this interface address in detail? Do we need to synchronize anything? =
Any concrete use cases?

So, how should we proceed? I could check in my current stuff, so that =
you can review it and merge it with your version. Of course, we can =
proceed the other way round too. What do you prefer?

Regards,
Juergen


P.S.:
Orion 2.0 has just been released. Hurray, it isn't dead! ;-) Seriously, =
I will definitely look at it soon. Hopefully, the web stuff is fully =
Servlet 2.3 compliant now.


> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Thursday, March 20, 2003 1:17 AM
> To: spr...@li...
> Subject: [Springframework-developer] Update
>=20
>=20
> Hi Guys,
>=20
> In case you're wondering why I've been silent lately I've
> been offline while my 18-month old son has been in hospital=20
> for heart surgery.  He's now recovering well after a bit of a=20
> scare last weekend.
>=20
> In the meantime I've been doing some work on Spring. I've
> continued to make some enhancements to the=20
> AbstractBeanFactory, which I'll commit early next week.
>=20
> AOP
>=20
> I've also reimplemented the AOP packages, and am very pleased
> with the results. (Developed test first, naturally, with 94%=20
> test coverage.) I'll also check this in in a few days. It=20
> builds on the new FactoryBean support, and I think is mature=20
> enough to make 0.9, if not 0.8 (depending on when we do the=20
> releases). The core AOP framework package is surprisingly=20
> simple: there's probably less code in it than the JDBC stuff.
>=20
> So please don't bother looking at the old AOP package...the
> new packages use the same concepts, but I think are a=20
> significant improvement.
>=20
>=20
> TRANSACTION MANAGEMENT
>=20
> Following a suggestion from Yann that reminded me of my
> original plans, I'm looking at trying to do for JTA what=20
> Spring does for JDBC: simplifying API using callbacks, and a=20
> meaningful hierarchy of runtime exceptions. One of the=20
> reasons JTA is a pain to use is that not only are all=20
> exceptions checked, there's no common superclass so they all=20
> need to be caught individually.
>=20
> I'm planning a new com.interface21.transaction package
> analogous to the com.interface21.dao package defining the=20
> exception hierarchy. A com.interface21.jta package (which I=20
> originally had but dropped for the first Spring release) will=20
> contain a JTA counterpart of the JdbcTemplate, using a=20
> similar calllback approach. Not sure whether this will make=20
> 1.0 or any interim release.
>=20
> An AOP transaction interceptor will offer CMT via AOP,
> building on this common tx infrastructure. I'll be checking=20
> in an experimental version of this next week. I think AOP has=20
> the potential to do much more powerful CMT than EJB. For=20
> example, it's possible to specify which checked exceptions=20
> should cause automatic rollback. This is impossible with EJB.=20
> Also, different transaction interceptors could be used for=20
> each target platform: e.g. Tomcat/Tyrex, Orion, WebLogic or=20
> JBoss. This would ensure that application code was truly portable.
>=20
>=20
> VOLUNTEERS WANTED
>=20
> I've designed a generic TransactionInterceptor that uses a
> PlatformTransactionManager interface that plugs into a=20
> potentially server-specific tx mgt API. (There are things to=20
> do with isolation levels etc. for which it's good to be able=20
> to use proprietary extensions.) I'm planning to do a=20
> JTA-based portable implementation, but I'd love volunteers to=20
> write PlatformTransactionManager implementations that could=20
> be used with particular servers, such as
> - JBoss
> - Tomcat/Tyrex
> - WebLogic
> - Orion
>=20
> I think it will also be important to have sample apps testing
> and demonstrating this functionality. I think it's going to=20
> be tremendously powerful, yet easy to use.
>=20
> Regards,
> Rod
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Does your code think in ink?
> You could win a Tablet PC. Get a free Tablet PC hat just for playing.=20
> What are you waiting for?=20
> http://ads.sourceforge.net/cgi-> bin/redirect.pl?micr5043en
>=20
>=20
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

[Springframework-developer] Update

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

Hi Guys,

In case you're wondering why I've been silent lately I've been offline while
my 18-month old son has been in hospital for heart surgery.  He's now
recovering well after a bit of a scare last weekend.

In the meantime I've been doing some work on Spring. I've continued to make
some enhancements to the AbstractBeanFactory, which I'll commit early next
week.

AOP

I've also reimplemented the AOP packages, and am very pleased with the
results. (Developed test first, naturally, with 94% test coverage.) I'll
also check this in in a few days. It builds on the new FactoryBean support,
and I think is mature enough to make 0.9, if not 0.8 (depending on when we
do the releases). The core AOP framework package is surprisingly simple:
there's probably less code in it than the JDBC stuff.

So please don't bother looking at the old AOP package...the new packages use
the same concepts, but I think are a significant improvement.


TRANSACTION MANAGEMENT

Following a suggestion from Yann that reminded me of my original plans, I'm
looking at trying to do for JTA what Spring does for JDBC: simplifying API
using callbacks, and a meaningful hierarchy of runtime exceptions. One of
the reasons JTA is a pain to use is that not only are all exceptions
checked, there's no common superclass so they all need to be caught
individually.

I'm planning a new com.interface21.transaction package analogous to the
com.interface21.dao package defining the exception hierarchy. A
com.interface21.jta package (which I originally had but dropped for the
first Spring release) will contain a JTA counterpart of the JdbcTemplate,
using a similar calllback approach. Not sure whether this will make 1.0 or
any interim release.

An AOP transaction interceptor will offer CMT via AOP, building on this
common tx infrastructure. I'll be checking in an experimental version of
this next week. I think AOP has the potential to do much more powerful CMT
than EJB. For example, it's possible to specify which checked exceptions
should cause automatic rollback. This is impossible with EJB. Also,
different transaction interceptors could be used for each target platform:
e.g. Tomcat/Tyrex, Orion, WebLogic or JBoss. This would ensure that
application code was truly portable.


VOLUNTEERS WANTED

I've designed a generic TransactionInterceptor that uses a
PlatformTransactionManager interface that plugs into a potentially
server-specific tx mgt API. (There are things to do with isolation levels
etc. for which it's good to be able to use proprietary extensions.) I'm
planning to do a JTA-based portable implementation, but I'd love volunteers
to write PlatformTransactionManager implementations that could be used with
particular servers, such as
- JBoss
- Tomcat/Tyrex
- WebLogic
- Orion

I think it will also be important to have sample apps testing and
demonstrating this functionality. I think it's going to be tremendously
powerful, yet easy to use.

Regards,
Rod

Re: [Springframework-developer] mock objects

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

Thanks for this, Juergen. I agree with the idea of making mock objects
generic. The old package names were a quick hack I forgot to change before I
did the initial CVS drop.

A couple of thoughts:
- The EJB mocks (from memory) aren't complete and I was considering dropping
them. In my experience using mock objects is about the only way to unit test
EJBs properly, but unit testing EJBs is still prohibitively difficult. One
of the many things wrong with EJB. Moving forward I see Spring offering an
*alternative* to EJB, via AOP.
- I've increasingly started to use EasyMock rather than custom mocks, with
very good results. As in the JdbcTemplate test suite, which no longer uses
the JDBC test classes.

Rod

----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Friday, March 14, 2003 6:52 PM
Subject: [Springframework-developer] mock objects


Hi everybody,

I'm currently trying to integrate the basic mock objects from the test tree
into the src tree, on the occasion of writing some test suites for an
application project that uses Spring. The rationale behind this is that most
of the mock objects are not just useful for Spring tests but also for
application tests. This demands including them in the Spring distribution,
and thus moving them to the main source tree. Besides, the "servletapi",
"mo.ejb", and "jdbc" package names in the test tree aren't proper anyway.

My main need are the JNDI mocks that allow for building a JNDI tree with the
application's environment, containing JDBC data sources and in our case
Hibernate session factories - completely without any container. To achieve
this, I've created a new SimpleDataSource mock that simply returns new
connections on every getConnection call - which works nicely with Hibernate
(BTW, in contrast to SingleConnectionDataSource that cannot handle standard
Connection.close calls). TestDataSource is now in com.interface21.jdbc.core
in the test tree, derived from SimpleDataSource.

Thus, I've moved the JNDI mocks to com.interface21.jndi.mock, and the JDBC
mocks (SimpleDataSource and SingleConnectionDataSource) to
com.interface21.jdbc.mock. Consequently, I've additionally moved the 2 EJB
mocks to com.interface21.ejb.mock, and the Servlet mocks to
com.interface21.web.mock. I don't use the latter 2 for application tests
currently, but I might choose to do so sometime.

Of course, this step adds a few classes to the main source tree and to the
distribution JARS, but that couple of KBs is hardly worth thinking about.
I'd mainly like to know if anyone objects to moving these mock objects to
the main source tree as a matter of principle, and if the new package names
would be OK.

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
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] ErrorCoded changes integrated

[Tony F. <ton...@ya...>]

After rethinking the "Object getControlledBy()" last night by first task today was to remove it from the MessageSourceResolvable interface and tell you about it.  I agree, it's totally something the Impl knows about and it was an artifact from refactoring I did on my initial coding.  Please remove it when you are making your changes.
In regards to the call to "getMessage()" (no params) within the toString() method.  I have no objection to this being removed.  It was put there to conform to what was in some code I saw that Rod had done to show internal state of an object (prior to us having the msg resolve).
No objections to moving around of the params, or naming them consistently.
I'm also not married to the keeping of the getLocale() on the MessageSourceResolvable interface.  I think you are right that most of the time it won't be needed - I leave this one up to the group.
As far as having the overload "getMessage(MessageSourceResolvable)" on the MessageSource interface, I also concur that if you remove the getLocale() from the MessageSourceResolvable interface, this overload should also be removed.
Very good feedback.  Thanks.
 jürgen_höller_[werk3AT] <jue...@we...> wrote:Tony,

Let me move this discussion to the developer list.

I consider "getControlledBy()" a method of a MessageSourceResolvable implementation, not of the interface itself. I simply don't see a reason for it needing to be in the interface. The toString() method is an implementation detail, not to be respected in the interface. A concrete MessageSourceResolvable can add any internal properties that it likes to, or be implemented as inner class to have access to the state of the surrounding "controlling" class.

Furthermore, your MessageSourceResolvableImpl.toString() implementation tries to actually resolve the message. IMO it shouldn't: MessageSourceResolvable(Impl) is a message specification, a parameter object used in the MessageSource interface. It shouldn't in turn know about the MessageSource interface, this creates an unnecessary two-way association. For use within the framework and especially within the validation package, a parameter object with a simple toString() is perfectly sufficient.

Concerning the locale property in the resolvable, I don't think that this does make sense. The locale is an attribute used at message resolution time, not at message creation time, at least not in the 99% normal case. Introducing double support here by giving MessageSourceResolvable a locale attribute is confusing and inconsistent with locale handling in the rest of the framework. I plead for one straightforward approach.

I'm aware that "getMessage(MessageSourceResolvable)" is in the MessageSource interface. It's just that this overloaded version is not necessary once that MessageSourceResolvable does not support a locale property anymore. I've also adapted the parameter order in the other getMessage versions, i.e. moved the locale to the end, to reflect the special role of the locale.

I consider the above mentioned simplifications necessary for keeping the framework clear and straightforward. We can add extra sophistication in the form of specialized subclasses in the future - if we ever need it. Thus, I've already applied the simplifications, including some according parameter renaming (no "error" names in the message source core) and slight refinement of the validation API (adding support for error arguments to the reject methods).

I will check this stuff in soon, together with the mock object moving and the minor new features described in a previous mail - if you haven't any strong objections.

Regards,
Juergen


-----Original Message-----
From: Tony Falabella [mailto:ton...@ya...] 
Sent: Monday, March 17, 2003 12:15 AM
To: jürgen höller [werk3AT]; rod...@in...
Subject: Re: ErrorCoded stuff ready for integration


Juergen, 

In response to your questions: 

-- What does "getControlledBy()" return? It returns an object, that being the object that it the "parent" or "owner" of this MessageSourceResolvable. This is a handle back to an object that might have a MsgSourceResolvable as an internal attribute. It allows the MsgSourceResolvable to make calls back to the parent if need be. Right now, you will see in the MessageSourceResolvableImpl that the toString() method uses this. 

-- I'm not sure why the resolvable contains a locale. This may be a bad example, but it's what I can come up with right now. Suppose a request comes in for Locale A that contains an eror and we don't want to resolve it right now. Let's say we store it in the database. Suppose later on we want to then reconstitue it to merely log the error to a file (thus no "HTTPRequest" was received for this to happen). Storing the locale with the object allows us to do this. 

-- Remove the "getMessage(MessageSourceResolvable)" method. Actually this is on the MessageSource interface, not on the MessageSourceResolvable interface. Similarly to being able to resolve a message from a MessageSource via getMessage(errorCode, errorArgs, locale, defaultMessage) why not allow the caller to just pass in a MessageSourceResolvable? They could do this by newing one themselves - an unlikely use of it, or by passing in one they already have a handle to - see examples in the code that already do this. Remember, a MessageSourceResolvable basically is just the 4 attributes you are passing into the "getMessage(errorCode, errorArgs, locale, defaultMessage)" method anyway. Let the caller decide what method is easier for them to call.


-----Original Message-----
From: Tony Falabella [mailto:ton...@ya...] 
Sent: Sunday, March 16, 2003 11:38 PM
To: spr...@li...
Subject: [Springframework-developer] ErrorCoded changes integrated


I have just integrated a lot of changes to accomplish 2 main goals:
1) To resolve messages from a MessageSource (ResourceBundle) using a "code"+locale
as the key that message.
2) To allow messages being resolved to take arguments in and have them be substituted
in the message returned.
I'll start with the high level description of what I've done. First, I changed the
MessageSource interface to have the following API:
String getMessage(MessageSourceResolvable resolvable) throws NoSuchMessageException;
String getMessage(MessageSourceResolvable resolvable, Locale locale) throws NoSuchMessageException;
String getMessage(String code, Locale locale, Object args[]) throws NoSuchMessageException;
String getMessage(String code, Locale locale, Object args[], String defaultMessage);
You'll notice 2 new overloads that take in a "MessageSourceResolvable". This is a new
interface I've introduced and it has this API:
public Object getControlledBy();
public String getDefaultMessage();
public Object[] getErrorArgs();
public String getErrorCode();
public Locale getLocale();
Basically, the thought is anyone that wishes to have something resolve it's messages from a MessageSource
need only implement this interface and the MessageSource will know how to return the message.
Notice that there are no setters on this interface - thus from the point of view of
a method receiving a MessageSourceResolvable object it is immutable. 
Generally anyone implementing this interface will provide appropriate constructors taking in similar arguments. 
The "MessageSourceResolvableImpl" class is a default implementation of this interface with the 
appropriate constructors and a good toString() method for showing the internal state.
Also notice the "getMessage(MessageSourceResolvable resolvable, Locale locale)" overload.
Since a MessageSourceResolvable is immutable it's values will generally be set only during
it's construction. It is quite possible that the MessageSourceResolvable might be
created during one HTTPRequest. The message to be displayed to the user might not occur
until another HTTPRequest arrives. Since the Spring Framework accommodates being able to
change the Locale on a HTTPRequest level, you need the ability to pass in a locale to the 
getMessage(...) method. This version of the method will use the locale arg passed in rather
than any locale attribute value that may have already been stored on the immutable MessageSourceResolvable.
for message resolution.

Also, a convience class named com.interface21.util.ObjectArrayUtils was introduced. This is
a static helper class that aids you in converting scalars into Object arrays. Perhaps useful
in the creation of the "Object[] args" parameter.


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] ErrorCoded changes integrated

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

Tony,

Let me move this discussion to the developer list.

I consider "getControlledBy()" a method of a MessageSourceResolvable =
implementation, not of the interface itself. I simply don't see a reason =
for it needing to be in the interface. The toString() method is an =
implementation detail, not to be respected in the interface. A concrete =
MessageSourceResolvable can add any internal properties that it likes =
to, or be implemented as inner class to have access to the state of the =
surrounding "controlling" class.

Furthermore, your MessageSourceResolvableImpl.toString() implementation =
tries to actually resolve the message. IMO it shouldn't: =
MessageSourceResolvable(Impl) is a message specification, a parameter =
object used in the MessageSource interface. It shouldn't in turn know =
about the MessageSource interface, this creates an unnecessary two-way =
association. For use within the framework and especially within the =
validation package, a parameter object with a simple toString() is =
perfectly sufficient.

Concerning the locale property in the resolvable, I don't think that =
this does make sense. The locale is an attribute used at message =
resolution time, not at message creation time, at least not in the 99% =
normal case. Introducing double support here by giving =
MessageSourceResolvable a locale attribute is confusing and inconsistent =
with locale handling in the rest of the framework. I plead  for one =
straightforward approach.

I'm aware that "getMessage(MessageSourceResolvable)" is in the =
MessageSource interface. It's just that this overloaded version is not =
necessary once that MessageSourceResolvable does not support a locale =
property anymore. I've also adapted the parameter order in the other =
getMessage versions, i.e. moved the locale to the end, to reflect the =
special role of the locale.

I consider the above mentioned simplifications necessary for keeping the =
framework clear and straightforward. We can add extra sophistication in =
the form of specialized subclasses in the future - if we ever need it. =
Thus, I've already applied the simplifications, including some according =
parameter renaming (no "error" names in the message source core) and =
slight refinement of the validation API (adding support for error =
arguments to the reject methods).

I will check this stuff in soon, together with the mock object moving =
and the minor new features described in a previous mail - if you haven't =
any strong objections.

Regards,
Juergen


-----Original Message-----
From: Tony Falabella [mailto:ton...@ya...]=20
Sent: Monday, March 17, 2003 12:15 AM
To: j=FCrgen h=F6ller [werk3AT]; rod...@in...
Subject: Re: ErrorCoded stuff ready for integration


Juergen,=20

In response to your questions:=20

-- What does "getControlledBy()" return?  It returns an object, that =
being the object that it the "parent" or "owner" of this =
MessageSourceResolvable.  This is a handle back to an object that might =
have a MsgSourceResolvable as an internal attribute.  It allows the =
MsgSourceResolvable to make calls back to the parent if need be.  Right =
now, you will see in the MessageSourceResolvableImpl that the toString() =
method uses this. =20

-- I'm not sure why the resolvable contains a locale.  This may be a bad =
example, but it's what I can come up with right now.  Suppose a request =
comes in for Locale A that contains an eror and we don't want to resolve =
it right now.  Let's say we store it in the database.  Suppose later on =
we want to then reconstitue it to merely log the error to a file (thus =
no "HTTPRequest" was received for this to happen).  Storing the locale =
with the object allows us to do this. =20

-- Remove the "getMessage(MessageSourceResolvable)" method.   Actually =
this is on the MessageSource interface, not on the =
MessageSourceResolvable interface.  Similarly to being able to resolve a =
message from a MessageSource via getMessage(errorCode, errorArgs, =
locale, defaultMessage) why not allow the caller to just pass in a =
MessageSourceResolvable?  They could do this by newing one themselves - =
an unlikely use of it, or by passing in one they already have a handle =
to - see examples in the code that already do this.  Remember, a =
MessageSourceResolvable basically is just the 4 attributes you are =
passing into the "getMessage(errorCode, errorArgs, locale, =
defaultMessage)" method anyway.  Let the caller decide what method is =
easier for them to call.


-----Original Message-----
From: Tony Falabella [mailto:ton...@ya...]=20
Sent: Sunday, March 16, 2003 11:38 PM
To: spr...@li...
Subject: [Springframework-developer] ErrorCoded changes integrated


I have just integrated a lot of changes to accomplish 2 main goals:
1) To resolve messages from a MessageSource (ResourceBundle) using a =
"code"+locale
   as the key that message.
2) To allow messages being resolved to take arguments in and have them =
be substituted
   in the message returned.
I'll start with the high level description of what I've done.  First, I =
changed the
MessageSource interface to have the following API:
 String getMessage(MessageSourceResolvable resolvable) throws =
NoSuchMessageException;
        String getMessage(MessageSourceResolvable resolvable, Locale =
locale) throws NoSuchMessageException;
        String getMessage(String code, Locale locale, Object args[]) =
throws NoSuchMessageException;
        String getMessage(String code, Locale locale, Object args[], =
String defaultMessage);
You'll notice 2 new overloads that take in a "MessageSourceResolvable".  =
This is a new
interface I've introduced and it has this API:
 public Object getControlledBy();
 public String getDefaultMessage();
 public Object[] getErrorArgs();
 public String getErrorCode();
 public Locale getLocale();
Basically, the thought is anyone that wishes to have something resolve =
it's messages from a MessageSource
need only implement this interface and the MessageSource will know how =
to return the message.
Notice that there are no setters on this interface - thus from the point =
of view of
a method receiving a MessageSourceResolvable object it is immutable. =20
Generally anyone implementing this interface will provide appropriate =
constructors taking in similar arguments. =20
The "MessageSourceResolvableImpl" class is a default implementation of =
this interface with the=20
appropriate constructors and a good toString() method for showing the =
internal state.
Also notice the "getMessage(MessageSourceResolvable resolvable, Locale =
locale)" overload.
Since a MessageSourceResolvable is immutable it's values will generally =
be set only during
it's construction.  It is quite possible that the =
MessageSourceResolvable might be
created during one HTTPRequest.  The message to be displayed to the user =
might not occur
until another HTTPRequest arrives.  Since the Spring Framework =
accommodates being able to
change the Locale on a HTTPRequest level, you need the ability to pass =
in a locale to the=20
getMessage(...) method.  This version of the method will use the locale =
arg passed in rather
than any locale attribute value that may have already been stored on the =
immutable MessageSourceResolvable.
for message resolution.

Also, a convience class named com.interface21.util.ObjectArrayUtils was =
introduced.  This is
a static helper class that aids you in converting scalars into Object =
arrays.  Perhaps useful
in the creation of the "Object[] args" parameter.

[Springframework-developer] ANT Build File suggestion

[Tony F. <ton...@ya...>]

What does everyone think of making a small modification to the build.xml file to include descriptions of the tasks available to be run?  

Right now only 2 tasks have a description associated with them.  Thus when you do: "ant -projecthelp" only these 2 tasks show up.  Here is the output:

 Buildfile: build.xml
 Main targets:

  checkstyle  Runs the checkstyle optional task to check for adherence to coding conventions
  format      Formats '.java' files (that are writable) contained within src dir

 Default target: usage


Since the default task is the "usage" task, and it has not been kept up to date with descriptions, I think it would benefit us to just add a simple description to each task that is available in ant.

This means that instead of having this:
 <target name="prepare" depends="init">

We'd have this:
 <target name="prepare" description="Prepares the project for building" depends="init">

[Springframework-developer] ErrorCoded changes integrated

[Tony F. <ton...@ya...>]

I have just integrated a lot of changes to accomplish 2 main goals:
1) To resolve messages from a MessageSource (ResourceBundle) using a "code"+locale
   as the key that message.
2) To allow messages being resolved to take arguments in and have them be substituted
   in the message returned.

I'll start with the high level description of what I've done.  First, I changed the
MessageSource interface to have the following API:
 String getMessage(MessageSourceResolvable resolvable) throws NoSuchMessageException;
        String getMessage(MessageSourceResolvable resolvable, Locale locale) throws NoSuchMessageException;
        String getMessage(String code, Locale locale, Object args[]) throws NoSuchMessageException;
        String getMessage(String code, Locale locale, Object args[], String defaultMessage);

You'll notice 2 new overloads that take in a "MessageSourceResolvable".  This is a new
interface I've introduced and it has this API:
 public Object getControlledBy();
 public String getDefaultMessage();
 public Object[] getErrorArgs();
 public String getErrorCode();
 public Locale getLocale();

Basically, the thought is anyone that wishes to have something resolve it's messages from a MessageSource
need only implement this interface and the MessageSource will know how to return the message.
Notice that there are no setters on this interface - thus from the point of view of
a method receiving a MessageSourceResolvable object it is immutable.  

Generally anyone implementing this interface will provide appropriate constructors taking in similar arguments.  
The "MessageSourceResolvableImpl" class is a default implementation of this interface with the 
appropriate constructors and a good toString() method for showing the internal state.

Also notice the "getMessage(MessageSourceResolvable resolvable, Locale locale)" overload.
Since a MessageSourceResolvable is immutable it's values will generally be set only during
it's construction.  It is quite possible that the MessageSourceResolvable might be
created during one HTTPRequest.  The message to be displayed to the user might not occur
until another HTTPRequest arrives.  Since the Spring Framework accommodates being able to
change the Locale on a HTTPRequest level, you need the ability to pass in a locale to the 
getMessage(...) method.  This version of the method will use the locale arg passed in rather
than any locale attribute value that may have already been stored on the immutable MessageSourceResolvable.
for message resolution.


Also, a convience class named com.interface21.util.ObjectArrayUtils was introduced.  This is
a static helper class that aids you in converting scalars into Object arrays.  Perhaps useful
in the creation of the "Object[] args" parameter.

 

For those interested in knowing the details of all classes included in this change, read on.


----------------------------------------------------

NEW
-------------------
MessageSourceResolvable - new
 New interface that contains these methods:
  public Object getControlledBy();
      public String getDefaultMessage();
      public Object[] getErrorArgs();
      public String getErrorCode();
      public Locale getLocale();
     Thought is this interface will be implemented by anyone that wishes to be able to
     resolve their message from a messageSource.  Example of a few of the classes 
     using this interface are "ObjectError" and "FieldError" (subclass of ObjectError).

MessageSourceResolvableImpl - new
 A default implementation of the new MessageSourceResolvable interface.  The
 "ObjectError" class subclasses from this.

ParameterizableErrorCodedPropertyVetoException - new
 Subclassed ErrorCodedPropertyVetoException and added ability to also take in args.

ParameterizableErrorCoded - new
 New sub-interface to ErrorCoded that contains a single method:
   Object[] getErrorArgs();
 
ObjectArrayUtils - new
 From a suggestion from Rod.  
 Contains static APIs like:
     public static Object[] toArray(boolean arg1, boolean arg2, boolean arg3) {

 Here is part of the JavaDocs:
  * Miscellaneous utility methods for creating an object array from
  * a bunch of primative args.  This utility class is especially
  * useful for classes implementing the ParameterizableErrorCoded interface.
  * Since there are so many combinations of primitives that can be passed in
  * to create an Object array from there are the following limitations.
  * CURRENT LIMITATIONS:
  * 1) Only implements overload for up to 9 args of SAME PRIMITIVE TYPE.
  * 2) Implements a helper overload for creating an array from up to 9 args
  *    of type object (not a big help, but it saves user from doing "new Object[] {...}"
  *    and it's consistent.
  * 3) Only implements overload for up to 5 args of all combinations
  *    SAME PRIMITIVE TYPE + any Objects sprinkled in between that primitive type
  *    (as it's assumed this will be a frequently used combo).

ResourceBundleMessageSourceTestSuite - new

StaticMessageSourceTestSuite - new

test\com\interface21\web\context\WEB-INF\context-messages.properties - deleted
 Replaced with specific file for the locales.

test\com\interface21\web\context\WEB-INF\context-messages_en_GB.properties - new

test\com\interface21\web\context\WEB-INF\context-messages_en_US.properties - new
 (and moved entry from "context-messages.properties" into here)

 

CHANGED
-------------------
ErrorCodedPropertyVetoException - chg
 More explicit JavaDocs.  Added overload to constructor so could subclass
 with a certain constructor.

MessageSource - chg
 This interface now has 4 overloads (as opposed to 2).  Two of the overloads take in
 a new arg "MessageSourceResolvable" (a new interface I introduced).
 String getMessage(MessageSourceResolvable resolvable) throws NoSuchMessageException;
        String getMessage(MessageSourceResolvable resolvable, Locale locale) throws NoSuchMessageException;
        String getMessage(String code, Locale locale, Object args[]) throws NoSuchMessageException;
        String getMessage(String code, Locale locale, Object args[], String defaultMessage);

NoSuchMessageException - chg
 now has a (code, locale) constructor as well as the old (code) constructor

AbstractApplicationContext - chg
 made the getMessage(...) methods conform to the new MessageSource interface.
**AbstractMsgSourceResolver

AbstractNestingMessageSource - chg
 Ultimately, the core of what I've changed.  The API for all the getMessage(...)
 methods conforms to the MessageSource interface.  I've also taken code from
 Struts for how they resolve messages from ResourceBundles and added functionality
 to do argument replacement.


MessageSourceResourceBundle - chg
 Changed param name of "key" to "code" (conforms with rest of errorCode stuff).  Also
 had to change call made internally to getMessage(...) method since API changed.

StaticApplicationContext - chg
 Changed API of one method from:
  public String addMessage(String code, String message) {
 to:
         public void addMessage(String code, Locale locale, String defaultMessage) {

StaticMessageSource - chg
 Changed API of one method from:
  public String addMessage(String code, String message) {
 to:
  public void addMessage(String code, Locale locale, String defaultMessage) {
 


BindException - chg
 Changed method APIs to conform to/emulate new MessageSource API args.

DataBinder - chg
 Changed method APIs to conform to/emulate new MessageSource API args.

Errors - chg
 Changed method APIs to conform to/emulate new MessageSource API args.

FieldError - chg
 Added a bunch of constructor overloads to conform to/emulate new MessageSource 
 API args.
 Changed the toString() method to return more about internal state.

ObjectError - chg
 Reparented it to MessageSourceResolvableImpl (thus implements MessageSourceResolvable int).
 Added a bunch of constructor overloads to conform to/emulate new MessageSource 
 API args.
 Changed the toString() method to return more about internal state.

EscapedErrors - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

RequestContext - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

RequestContextUtils - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

BindTag - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

MessageTag - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

TagInWebApplicationContext - chg
 Changed the orig 2 resolveMessage(...) APIs to now be 4 methods with the same signatures
 that are on the MessageSource int only named with resolveMessage:
  String resolveMessage(MessageSourceResolvable resolvable) throws NoSuchMessageException;
         String resolveMessage(MessageSourceResolvable resolvable, Locale locale) throws NoSuchMessageException;
         String resolveMessage(String code, Locale locale, Object args[]) throws NoSuchMessageException;
         String resolveMessage(String code, Locale locale, Object args[], String defaultMessage);

AbstractApplicationContextTests - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

StaticApplicationContextTestSuite - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

 

[Springframework-developer] ErrorCoded changes integrated

[Tony F. <ton...@ya...>]

I have just integrated a lot of changes to accomplish 2 main goals:
1) To resolve messages from a MessageSource (ResourceBundle) using a "code"+locale
   as the key that message.
2) To allow messages being resolved to take arguments in and have them be substituted
   in the message returned.

I'll start with the high level description of what I've done.  First, I changed the
MessageSource interface to have the following API:
 String getMessage(MessageSourceResolvable resolvable) throws NoSuchMessageException;
        String getMessage(MessageSourceResolvable resolvable, Locale locale) throws NoSuchMessageException;
        String getMessage(String code, Locale locale, Object args[]) throws NoSuchMessageException;
        String getMessage(String code, Locale locale, Object args[], String defaultMessage);

You'll notice 2 new overloads that take in a "MessageSourceResolvable".  This is a new
interface I've introduced and it has this API:
 public Object getControlledBy();
 public String getDefaultMessage();
 public Object[] getErrorArgs();
 public String getErrorCode();
 public Locale getLocale();

Basically, the thought is anyone that wishes to have something resolve it's messages from a MessageSource
need only implement this interface and the MessageSource will know how to return the message.
Notice that there are no setters on this interface - thus from the point of view of
a method receiving a MessageSourceResolvable object it is immutable.  

Generally anyone implementing this interface will provide appropriate constructors taking in similar arguments.  
The "MessageSourceResolvableImpl" class is a default implementation of this interface with the 
appropriate constructors and a good toString() method for showing the internal state.

Also notice the "getMessage(MessageSourceResolvable resolvable, Locale locale)" overload.
Since a MessageSourceResolvable is immutable it's values will generally be set only during
it's construction.  It is quite possible that the MessageSourceResolvable might be
created during one HTTPRequest.  The message to be displayed to the user might not occur
until another HTTPRequest arrives.  Since the Spring Framework accommodates being able to
change the Locale on a HTTPRequest level, you need the ability to pass in a locale to the 
getMessage(...) method.  This version of the method will use the locale arg passed in rather
than any locale attribute value that may have already been stored on the immutable MessageSourceResolvable.
for message resolution.


Also, a convience class named com.interface21.util.ObjectArrayUtils was introduced.  This is
a static helper class that aids you in converting scalars into Object arrays.  Perhaps useful
in the creation of the "Object[] args" parameter.

 

For those interested in knowing the details of all classes included in this change, read on.


----------------------------------------------------

NEW
-------------------
MessageSourceResolvable - new
 New interface that contains these methods:
  public Object getControlledBy();
      public String getDefaultMessage();
      public Object[] getErrorArgs();
      public String getErrorCode();
      public Locale getLocale();
     Thought is this interface will be implemented by anyone that wishes to be able to
     resolve their message from a messageSource.  Example of a few of the classes 
     using this interface are "ObjectError" and "FieldError" (subclass of ObjectError).

MessageSourceResolvableImpl - new
 A default implementation of the new MessageSourceResolvable interface.  The
 "ObjectError" class subclasses from this.

ParameterizableErrorCodedPropertyVetoException - new
 Subclassed ErrorCodedPropertyVetoException and added ability to also take in args.

ParameterizableErrorCoded - new
 New sub-interface to ErrorCoded that contains a single method:
   Object[] getErrorArgs();
 
ObjectArrayUtils - new
 From a suggestion from Rod.  
 Contains static APIs like:
     public static Object[] toArray(boolean arg1, boolean arg2, boolean arg3) {

 Here is part of the JavaDocs:
  * Miscellaneous utility methods for creating an object array from
  * a bunch of primative args.  This utility class is especially
  * useful for classes implementing the ParameterizableErrorCoded interface.
  * Since there are so many combinations of primitives that can be passed in
  * to create an Object array from there are the following limitations.
  * CURRENT LIMITATIONS:
  * 1) Only implements overload for up to 9 args of SAME PRIMITIVE TYPE.
  * 2) Implements a helper overload for creating an array from up to 9 args
  *    of type object (not a big help, but it saves user from doing "new Object[] {...}"
  *    and it's consistent.
  * 3) Only implements overload for up to 5 args of all combinations
  *    SAME PRIMITIVE TYPE + any Objects sprinkled in between that primitive type
  *    (as it's assumed this will be a frequently used combo).

ResourceBundleMessageSourceTestSuite - new

StaticMessageSourceTestSuite - new

test\com\interface21\web\context\WEB-INF\context-messages.properties - deleted
 Replaced with specific file for the locales.

test\com\interface21\web\context\WEB-INF\context-messages_en_GB.properties - new

test\com\interface21\web\context\WEB-INF\context-messages_en_US.properties - new
 (and moved entry from "context-messages.properties" into here)

 

CHANGED
-------------------
ErrorCodedPropertyVetoException - chg
 More explicit JavaDocs.  Added overload to constructor so could subclass
 with a certain constructor.

MessageSource - chg
 This interface now has 4 overloads (as opposed to 2).  Two of the overloads take in
 a new arg "MessageSourceResolvable" (a new interface I introduced).
 String getMessage(MessageSourceResolvable resolvable) throws NoSuchMessageException;
        String getMessage(MessageSourceResolvable resolvable, Locale locale) throws NoSuchMessageException;
        String getMessage(String code, Locale locale, Object args[]) throws NoSuchMessageException;
        String getMessage(String code, Locale locale, Object args[], String defaultMessage);

NoSuchMessageException - chg
 now has a (code, locale) constructor as well as the old (code) constructor

AbstractApplicationContext - chg
 made the getMessage(...) methods conform to the new MessageSource interface.
**AbstractMsgSourceResolver

AbstractNestingMessageSource - chg
 Ultimately, the core of what I've changed.  The API for all the getMessage(...)
 methods conforms to the MessageSource interface.  I've also taken code from
 Struts for how they resolve messages from ResourceBundles and added functionality
 to do argument replacement.


MessageSourceResourceBundle - chg
 Changed param name of "key" to "code" (conforms with rest of errorCode stuff).  Also
 had to change call made internally to getMessage(...) method since API changed.

StaticApplicationContext - chg
 Changed API of one method from:
  public String addMessage(String code, String message) {
 to:
         public void addMessage(String code, Locale locale, String defaultMessage) {

StaticMessageSource - chg
 Changed API of one method from:
  public String addMessage(String code, String message) {
 to:
  public void addMessage(String code, Locale locale, String defaultMessage) {
 


BindException - chg
 Changed method APIs to conform to/emulate new MessageSource API args.

DataBinder - chg
 Changed method APIs to conform to/emulate new MessageSource API args.

Errors - chg
 Changed method APIs to conform to/emulate new MessageSource API args.

FieldError - chg
 Added a bunch of constructor overloads to conform to/emulate new MessageSource 
 API args.
 Changed the toString() method to return more about internal state.

ObjectError - chg
 Reparented it to MessageSourceResolvableImpl (thus implements MessageSourceResolvable int).
 Added a bunch of constructor overloads to conform to/emulate new MessageSource 
 API args.
 Changed the toString() method to return more about internal state.

EscapedErrors - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

RequestContext - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

RequestContextUtils - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

BindTag - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

MessageTag - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

TagInWebApplicationContext - chg
 Changed the orig 2 resolveMessage(...) APIs to now be 4 methods with the same signatures
 that are on the MessageSource int only named with resolveMessage:
  String resolveMessage(MessageSourceResolvable resolvable) throws NoSuchMessageException;
         String resolveMessage(MessageSourceResolvable resolvable, Locale locale) throws NoSuchMessageException;
         String resolveMessage(String code, Locale locale, Object args[]) throws NoSuchMessageException;
         String resolveMessage(String code, Locale locale, Object args[], String defaultMessage);

AbstractApplicationContextTests - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

StaticApplicationContextTestSuite - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

 

[Springframework-developer] ErrorCoded changes integrated

[Tony F. <ton...@ya...>]

I have just integrated a lot of changes to accomplish 2 main goals:
1) To resolve messages from a MessageSource (ResourceBundle) using a "code"+locale
   as the key that message.
2) To allow messages being resolved to take arguments in and have them be substituted
   in the message returned.

I'll start with the high level description of what I've done.  First, I changed the
MessageSource interface to have the following API:
 String getMessage(MessageSourceResolvable resolvable) throws NoSuchMessageException;
        String getMessage(MessageSourceResolvable resolvable, Locale locale) throws NoSuchMessageException;
        String getMessage(String code, Locale locale, Object args[]) throws NoSuchMessageException;
        String getMessage(String code, Locale locale, Object args[], String defaultMessage);

You'll notice 2 new overloads that take in a "MessageSourceResolvable".  This is a new
interface I've introduced and it has this API:
 public Object getControlledBy();
 public String getDefaultMessage();
 public Object[] getErrorArgs();
 public String getErrorCode();
 public Locale getLocale();

Basically, the thought is anyone that wishes to have something resolve it's messages from a MessageSource
need only implement this interface and the MessageSource will know how to return the message.
Notice that there are no setters on this interface - thus from the point of view of
a method receiving a MessageSourceResolvable object it is immutable.  

Generally anyone implementing this interface will provide appropriate constructors taking in similar arguments.  
The "MessageSourceResolvableImpl" class is a default implementation of this interface with the 
appropriate constructors and a good toString() method for showing the internal state.

Also notice the "getMessage(MessageSourceResolvable resolvable, Locale locale)" overload.
Since a MessageSourceResolvable is immutable it's values will generally be set only during
it's construction.  It is quite possible that the MessageSourceResolvable might be
created during one HTTPRequest.  The message to be displayed to the user might not occur
until another HTTPRequest arrives.  Since the Spring Framework accommodates being able to
change the Locale on a HTTPRequest level, you need the ability to pass in a locale to the 
getMessage(...) method.  This version of the method will use the locale arg passed in rather
than any locale attribute value that may have already been stored on the immutable MessageSourceResolvable.
for message resolution.


Also, a convience class named com.interface21.util.ObjectArrayUtils was introduced.  This is
a static helper class that aids you in converting scalars into Object arrays.  Perhaps useful
in the creation of the "Object[] args" parameter.

 

For those interested in knowing the details of all classes included in this change, read on.


----------------------------------------------------

NEW
-------------------
MessageSourceResolvable - new
 New interface that contains these methods:
  public Object getControlledBy();
      public String getDefaultMessage();
      public Object[] getErrorArgs();
      public String getErrorCode();
      public Locale getLocale();
     Thought is this interface will be implemented by anyone that wishes to be able to
     resolve their message from a messageSource.  Example of a few of the classes 
     using this interface are "ObjectError" and "FieldError" (subclass of ObjectError).

MessageSourceResolvableImpl - new
 A default implementation of the new MessageSourceResolvable interface.  The
 "ObjectError" class subclasses from this.

ParameterizableErrorCodedPropertyVetoException - new
 Subclassed ErrorCodedPropertyVetoException and added ability to also take in args.

ParameterizableErrorCoded - new
 New sub-interface to ErrorCoded that contains a single method:
   Object[] getErrorArgs();
 
ObjectArrayUtils - new
 From a suggestion from Rod.  
 Contains static APIs like:
     public static Object[] toArray(boolean arg1, boolean arg2, boolean arg3) {

 Here is part of the JavaDocs:
  * Miscellaneous utility methods for creating an object array from
  * a bunch of primative args.  This utility class is especially
  * useful for classes implementing the ParameterizableErrorCoded interface.
  * Since there are so many combinations of primitives that can be passed in
  * to create an Object array from there are the following limitations.
  * CURRENT LIMITATIONS:
  * 1) Only implements overload for up to 9 args of SAME PRIMITIVE TYPE.
  * 2) Implements a helper overload for creating an array from up to 9 args
  *    of type object (not a big help, but it saves user from doing "new Object[] {...}"
  *    and it's consistent.
  * 3) Only implements overload for up to 5 args of all combinations
  *    SAME PRIMITIVE TYPE + any Objects sprinkled in between that primitive type
  *    (as it's assumed this will be a frequently used combo).

ResourceBundleMessageSourceTestSuite - new

StaticMessageSourceTestSuite - new

test\com\interface21\web\context\WEB-INF\context-messages.properties - deleted
 Replaced with specific file for the locales.

test\com\interface21\web\context\WEB-INF\context-messages_en_GB.properties - new

test\com\interface21\web\context\WEB-INF\context-messages_en_US.properties - new
 (and moved entry from "context-messages.properties" into here)

 

CHANGED
-------------------
ErrorCodedPropertyVetoException - chg
 More explicit JavaDocs.  Added overload to constructor so could subclass
 with a certain constructor.

MessageSource - chg
 This interface now has 4 overloads (as opposed to 2).  Two of the overloads take in
 a new arg "MessageSourceResolvable" (a new interface I introduced).
 String getMessage(MessageSourceResolvable resolvable) throws NoSuchMessageException;
        String getMessage(MessageSourceResolvable resolvable, Locale locale) throws NoSuchMessageException;
        String getMessage(String code, Locale locale, Object args[]) throws NoSuchMessageException;
        String getMessage(String code, Locale locale, Object args[], String defaultMessage);

NoSuchMessageException - chg
 now has a (code, locale) constructor as well as the old (code) constructor

AbstractApplicationContext - chg
 made the getMessage(...) methods conform to the new MessageSource interface.
**AbstractMsgSourceResolver

AbstractNestingMessageSource - chg
 Ultimately, the core of what I've changed.  The API for all the getMessage(...)
 methods conforms to the MessageSource interface.  I've also taken code from
 Struts for how they resolve messages from ResourceBundles and added functionality
 to do argument replacement.


MessageSourceResourceBundle - chg
 Changed param name of "key" to "code" (conforms with rest of errorCode stuff).  Also
 had to change call made internally to getMessage(...) method since API changed.

StaticApplicationContext - chg
 Changed API of one method from:
  public String addMessage(String code, String message) {
 to:
         public void addMessage(String code, Locale locale, String defaultMessage) {

StaticMessageSource - chg
 Changed API of one method from:
  public String addMessage(String code, String message) {
 to:
  public void addMessage(String code, Locale locale, String defaultMessage) {
 


BindException - chg
 Changed method APIs to conform to/emulate new MessageSource API args.

DataBinder - chg
 Changed method APIs to conform to/emulate new MessageSource API args.

Errors - chg
 Changed method APIs to conform to/emulate new MessageSource API args.

FieldError - chg
 Added a bunch of constructor overloads to conform to/emulate new MessageSource 
 API args.
 Changed the toString() method to return more about internal state.

ObjectError - chg
 Reparented it to MessageSourceResolvableImpl (thus implements MessageSourceResolvable int).
 Added a bunch of constructor overloads to conform to/emulate new MessageSource 
 API args.
 Changed the toString() method to return more about internal state.

EscapedErrors - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

RequestContext - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

RequestContextUtils - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

BindTag - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

MessageTag - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

TagInWebApplicationContext - chg
 Changed the orig 2 resolveMessage(...) APIs to now be 4 methods with the same signatures
 that are on the MessageSource int only named with resolveMessage:
  String resolveMessage(MessageSourceResolvable resolvable) throws NoSuchMessageException;
         String resolveMessage(MessageSourceResolvable resolvable, Locale locale) throws NoSuchMessageException;
         String resolveMessage(String code, Locale locale, Object args[]) throws NoSuchMessageException;
         String resolveMessage(String code, Locale locale, Object args[], String defaultMessage);

AbstractApplicationContextTests - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

StaticApplicationContextTestSuite - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

 

[Springframework-developer] ErrorCoded changes integrated

[Tony F. <ton...@ya...>]

I have just integrated a lot of changes to accomplish 2 main goals:
1) To resolve messages from a MessageSource (ResourceBundle) using a "code"+locale
   as the key that message.
2) To allow messages being resolved to take arguments in and have them be substituted
   in the message returned.

I'll start with the high level description of what I've done.  First, I changed the
MessageSource interface to have the following API:
 String getMessage(MessageSourceResolvable resolvable) throws NoSuchMessageException;
        String getMessage(MessageSourceResolvable resolvable, Locale locale) throws NoSuchMessageException;
        String getMessage(String code, Locale locale, Object args[]) throws NoSuchMessageException;
        String getMessage(String code, Locale locale, Object args[], String defaultMessage);

You'll notice 2 new overloads that take in a "MessageSourceResolvable".  This is a new
interface I've introduced and it has this API:
 public Object getControlledBy();
 public String getDefaultMessage();
 public Object[] getErrorArgs();
 public String getErrorCode();
 public Locale getLocale();

Basically, the thought is anyone that wishes to have something resolve it's messages from a MessageSource
need only implement this interface and the MessageSource will know how to return the message.
Notice that there are no setters on this interface - thus from the point of view of
a method receiving a MessageSourceResolvable object it is immutable.  

Generally anyone implementing this interface will provide appropriate constructors taking in similar arguments.  
The "MessageSourceResolvableImpl" class is a default implementation of this interface with the 
appropriate constructors and a good toString() method for showing the internal state.

Also notice the "getMessage(MessageSourceResolvable resolvable, Locale locale)" overload.
Since a MessageSourceResolvable is immutable it's values will generally be set only during
it's construction.  It is quite possible that the MessageSourceResolvable might be
created during one HTTPRequest.  The message to be displayed to the user might not occur
until another HTTPRequest arrives.  Since the Spring Framework accommodates being able to
change the Locale on a HTTPRequest level, you need the ability to pass in a locale to the 
getMessage(...) method.  This version of the method will use the locale arg passed in rather
than any locale attribute value that may have already been stored on the immutable MessageSourceResolvable.
for message resolution.


Also, a convience class named com.interface21.util.ObjectArrayUtils was introduced.  This is
a static helper class that aids you in converting scalars into Object arrays.  Perhaps useful
in the creation of the "Object[] args" parameter.

 

For those interested in knowing the details of all classes included in this change, read on.


----------------------------------------------------

NEW
-------------------
MessageSourceResolvable - new
 New interface that contains these methods:
  public Object getControlledBy();
      public String getDefaultMessage();
      public Object[] getErrorArgs();
      public String getErrorCode();
      public Locale getLocale();
     Thought is this interface will be implemented by anyone that wishes to be able to
     resolve their message from a messageSource.  Example of a few of the classes 
     using this interface are "ObjectError" and "FieldError" (subclass of ObjectError).

MessageSourceResolvableImpl - new
 A default implementation of the new MessageSourceResolvable interface.  The
 "ObjectError" class subclasses from this.

ParameterizableErrorCodedPropertyVetoException - new
 Subclassed ErrorCodedPropertyVetoException and added ability to also take in args.

ParameterizableErrorCoded - new
 New sub-interface to ErrorCoded that contains a single method:
   Object[] getErrorArgs();
 
ObjectArrayUtils - new
 From a suggestion from Rod.  
 Contains static APIs like:
     public static Object[] toArray(boolean arg1, boolean arg2, boolean arg3) {

 Here is part of the JavaDocs:
  * Miscellaneous utility methods for creating an object array from
  * a bunch of primative args.  This utility class is especially
  * useful for classes implementing the ParameterizableErrorCoded interface.
  * Since there are so many combinations of primitives that can be passed in
  * to create an Object array from there are the following limitations.
  * CURRENT LIMITATIONS:
  * 1) Only implements overload for up to 9 args of SAME PRIMITIVE TYPE.
  * 2) Implements a helper overload for creating an array from up to 9 args
  *    of type object (not a big help, but it saves user from doing "new Object[] {...}"
  *    and it's consistent.
  * 3) Only implements overload for up to 5 args of all combinations
  *    SAME PRIMITIVE TYPE + any Objects sprinkled in between that primitive type
  *    (as it's assumed this will be a frequently used combo).

ResourceBundleMessageSourceTestSuite - new

StaticMessageSourceTestSuite - new

test\com\interface21\web\context\WEB-INF\context-messages.properties - deleted
 Replaced with specific file for the locales.

test\com\interface21\web\context\WEB-INF\context-messages_en_GB.properties - new

test\com\interface21\web\context\WEB-INF\context-messages_en_US.properties - new
 (and moved entry from "context-messages.properties" into here)

 

CHANGED
-------------------
ErrorCodedPropertyVetoException - chg
 More explicit JavaDocs.  Added overload to constructor so could subclass
 with a certain constructor.

MessageSource - chg
 This interface now has 4 overloads (as opposed to 2).  Two of the overloads take in
 a new arg "MessageSourceResolvable" (a new interface I introduced).
 String getMessage(MessageSourceResolvable resolvable) throws NoSuchMessageException;
        String getMessage(MessageSourceResolvable resolvable, Locale locale) throws NoSuchMessageException;
        String getMessage(String code, Locale locale, Object args[]) throws NoSuchMessageException;
        String getMessage(String code, Locale locale, Object args[], String defaultMessage);

NoSuchMessageException - chg
 now has a (code, locale) constructor as well as the old (code) constructor

AbstractApplicationContext - chg
 made the getMessage(...) methods conform to the new MessageSource interface.
**AbstractMsgSourceResolver

AbstractNestingMessageSource - chg
 Ultimately, the core of what I've changed.  The API for all the getMessage(...)
 methods conforms to the MessageSource interface.  I've also taken code from
 Struts for how they resolve messages from ResourceBundles and added functionality
 to do argument replacement.


MessageSourceResourceBundle - chg
 Changed param name of "key" to "code" (conforms with rest of errorCode stuff).  Also
 had to change call made internally to getMessage(...) method since API changed.

StaticApplicationContext - chg
 Changed API of one method from:
  public String addMessage(String code, String message) {
 to:
         public void addMessage(String code, Locale locale, String defaultMessage) {

StaticMessageSource - chg
 Changed API of one method from:
  public String addMessage(String code, String message) {
 to:
  public void addMessage(String code, Locale locale, String defaultMessage) {
 


BindException - chg
 Changed method APIs to conform to/emulate new MessageSource API args.

DataBinder - chg
 Changed method APIs to conform to/emulate new MessageSource API args.

Errors - chg
 Changed method APIs to conform to/emulate new MessageSource API args.

FieldError - chg
 Added a bunch of constructor overloads to conform to/emulate new MessageSource 
 API args.
 Changed the toString() method to return more about internal state.

ObjectError - chg
 Reparented it to MessageSourceResolvableImpl (thus implements MessageSourceResolvable int).
 Added a bunch of constructor overloads to conform to/emulate new MessageSource 
 API args.
 Changed the toString() method to return more about internal state.

EscapedErrors - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

RequestContext - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

RequestContextUtils - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

BindTag - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

MessageTag - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

TagInWebApplicationContext - chg
 Changed the orig 2 resolveMessage(...) APIs to now be 4 methods with the same signatures
 that are on the MessageSource int only named with resolveMessage:
  String resolveMessage(MessageSourceResolvable resolvable) throws NoSuchMessageException;
         String resolveMessage(MessageSourceResolvable resolvable, Locale locale) throws NoSuchMessageException;
         String resolveMessage(String code, Locale locale, Object args[]) throws NoSuchMessageException;
         String resolveMessage(String code, Locale locale, Object args[], String defaultMessage);

AbstractApplicationContextTests - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

StaticApplicationContextTestSuite - chg
 Changed internal method calls to conform to/emulate new MessageSource API args.

 

[Springframework-developer] PropertiesConfigurer, Log4jConfig, getResourceAsStream

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

SSd2ZSByZWNlbnRseSBmaW5pc2hlZCBzb21lIG5ldyBtaW5vciBmZWF0dXJlczoNCg0KLSBQcm9w
ZXJ0aWVzQ29uZmlndXJlcjogQW4gQXBwbGljYXRpb25Db250ZXh0QXdhcmUgYmVhbiB0aGF0IHJl
YWRzIGEgY3VzdG9tIGNvbmZpZyAocHJvcGVydGllcykgZmlsZSBhbmQgc2V0cyBhcmJpdHJhcnkg
YmVhbiBwcm9wZXJ0aWVzIGFjY29yZGluZ2x5LiBUaGlzIGlzIG1lYW50IGZvciBhZG1pbmlzdHJh
dG9yIGNvbmZpZyBmaWxlcyAoYWRtaW5pc3RyYXRvcnMgc2hvdWxkbid0IGtub3cgYWJvdXQgYmVh
biBkZWZpbml0aW9uIGZpbGVzKSB0aGF0IHNpbXBseSBvdmVycmlkZSB2YXJpb3VzIGJlYW4gcHJv
cGVydHkgZGVmYXVsdHMuIFRoZSBjb25maWcgZmlsZSBmb3JtYXQgaXMgImJlYW5OYW1lLnByb3Bl
cnR5PXZhbHVlIiAtIGRlc2NyaXB0aXZlIGFuZCBoYW5keS4gSSdtIG5vdCBzdXJlIGFib3V0IHRo
ZSBuYW1lICJQcm9wZXJ0aWVzQ29uZmlndXJlciIgdGhvdWdoIC0gYW55IHN1Z2dlc3Rpb25zPyBN
YXliZSAiUHJvcGVydHlGaWxlQ29uZmlndXJlciI/DQoNCi0gTG9nNGpDb25maWc6IFNwZWNpYWwg
TG9nNEogaW5pdGlhbGl6YXRpb24gc3VwcG9ydCBmb3Igd2ViIGFwcHMgKGluIGNvbS5pbnRlcmZh
Y2UyMS53ZWIudXRpbC5sb2c0aiksIGluc3RlYWQgb2YgTG9nNEoncyBpbXBsaWNpdCBzdGFuZGFy
ZCBpbml0aWFsaXphdGlvbi4gQWxsb3dzIGZvciBsb2c0aiBjb25maWcgcmVmcmVzaCBjaGVja3Mg
dmlhIGNvbmZpZ3VyZUFuZFdhdGNoLCBhbmQgc3VwcG9ydHMgbG9nIGZpbGUgcm9vdCBkaXJlY3Rv
cmllcyBwZXIgd2ViIGFwcC4gVGhlIHNpbXBsZSByZXF1aXJlbWVudCBmb3IgdGhlIGxhdHRlciBp
cyB0aGF0IG9uZSBzaG91bGQgYmUgYWJsZSB0byBwdXQgbG9nIGZpbGVzIGluIHRoZSB3ZWIgYXBw
J3MgV0VCLUlORiBkaXJlY3RvcnksIHVzaW5nIGEgcGF0aCByZWxhdGl2ZSB0byB0aGUgd2ViIGFw
cCByb290LiBJJ3ZlIGFwcHJvYWNoZWQgdGhpcyBpc3N1ZSB2aWEgY3VzdG9tIEZpbGVBcHBlbmRl
ciBzdWJjbGFzc2VzIG5hbWVkIFJlbGF0aXZlUGF0aEZpbGVBcHBlbmRlciBhbmQgUmVsYXRpdmVQ
YXRoUm9sbGluZ0ZpbGVBcHBlbmRlciB0aGF0IGFkZCBzdXBwb3J0IGZvciBMb2c0akNvbmZpZydz
IGxvZ0ZpbGVSb290IHByb3BlcnR5LiBUaGVyZSBhcmUgYm90aCBhIExvZzRqQ29uZmlnTGlzdGVu
ZXIgYW5kIGEgTG9nNGpDb25maWdTZXJ2bGV0IHRoYXQgYXV0b21hdGljYWxseSBzZXQgdGhpcyBw
cm9wZXJ0eS4gQWRkaXRpb25hbGx5LCBMb2c0akNvbmZpZ1NlcnZsZXQgYWRkcyBzdXBwb3J0IGZv
ciBjdXN0b20gTG9nNEogY29uZmlnIGZpbGUgbG9jYXRpb25zIGFuZCBjb25maWd1cmFibGUgcmVm
cmVzaCBjaGVja3MuDQoNCi0gQXBwbGljYXRpb25Db250ZXh0LmdldFJlc291cmNlQXNTdHJlYW06
IEEgbmV3IG1ldGhvZCBvZiBBcHBsaWNhdGlvbkNvbnRleHQgdGhhdCBzdXBwb3J0cyBjb250ZXh0
LXJlbGF0aXZlIHJlc291cmNlIGxvYWRpbmcsIGFuYWxvZ291cyB0byBTZXJ2bGV0Q29udGV4dC5n
ZXRSZXNvdXJjZUFzU3RyZWFtLiBUaGUgZGVmYXVsdCBpbXBsZW1lbnRhdGlvbiBpbiBBYnN0cmFj
dEFwcGxpY2F0aW9uQ29udGV4dCBzdXBwb3J0cyBmdWxseSBxdWFsaWZpZWQgVVJMcywgYWJzb2x1
dGUgZmlsZSBwYXRocywgYW5kIGZpbGUgcGF0aHMgcmVsYXRpdmUgdG8gdGhlIFZNIGV4ZWN1dGlv
biBkaXJlY3RvcnkuIFRoZSBpbXBsZW1lbnRhdGlvbiBpbiBYbWxXZWJBcHBsaWNhdGlvbkNvbnRl
eHQgaW50ZXJwcmV0cyByZWxhdGl2ZSBmaWxlIHBhdGhzIGFzIHJlbGF0aXZlIHRvIHRoZSB3ZWIg
YXBwIHJvb3QgZGlyZWN0b3J5LiBUaGlzIGFsbG93cyBmb3IgbG9hZGluZyBvZiBmaWxlcyByZWxh
dGl2ZSB0byB0aGUgd2ViIGFwcCByb290IHdpdGhvdXQgaW50cm9kdWNpbmcgd2ViIGRlcGVuZGVu
Y2llcywgZS5nLiBpbiBBYnN0cmFjdFhtbEFwcGxpY2F0aW9uQ29udGV4dCwgUHJvcGVydGllc0Nv
bmZpZ3VyZXIsIGFuZCBWZWxvY2l0eUNvbmZpZ3VyZXIuIFJlbGF0aXZlIGZpbGUgcGF0aHMgYXJl
IHNpbXBseSBpbnRlcnByZXRlZCBhcyByZWxhdGl2ZSB0byB0aGUgVk0gZXhlY3V0aW9uIGRpcmVj
dG9yeSBpbiB0aGUgbm9uLXdlYiBjYXNlLg0KDQpUaGUgbGF0dGVyIGlzIGFscmVhZHkgY2hlY2tl
ZCBpbiBzaW5jZSBGcmlkYXksIGFjY29tcGFueWluZyB0aGUgbmV3IE1lc3NhZ2VTb3VyY2UgdW5p
dCB0ZXN0cy4gSSB3aWxsIGNoZWNrIGluIHRoZSBvdGhlciB0d28gc29vbiBpZiB0aGVyZSBhcmVu
J3QgYW55IGJldHRlciBzdWdnZXN0aW9ucyBpbiB0ZXJtcyBvZiBkaWZmZXJlbnQgc29sdXRpb25z
IHRvIHRoZSBzYW1lIHByb2JsZW1zLiANCg0KSnVlcmdlbg0KDQoNCkRJIErDvHJnZW4gSMO2bGxl
ciANClNlbmlvciBTeXN0ZW0gQXJjaGl0ZWN0IA0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXyANCg0Kd2VyazNBVFMgLSBkaXZpc2lvbiBzeXN0ZW1lbnR3aWNrbHVuZyANCnBhcnQg
b2Ygd2VyazNBVCBpbnRlcm5ldG1lZGllbiBvZWcgDQoNCmV1cm9wYXBsYXR6IDQgDQpBIC0gNDAy
MCBsaW56IA0KDQp0LiAgKzQzICgwKSA3MzIgNzEgNjUgMjkgDQpmLiAgKzQzICgwKSA3MzIgNzEg
NjUgMjkgMyANCmp1ZXJnZW4uaG9lbGxlckB3ZXJrM2F0LmNvbSANCnd3dy53ZXJrM2F0LmNvbSAN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQp3ZXJrM0FUUyAtIFdJUiBFTlRX
SUNLRUxOIEVSRk9MRyANCg0K

[Springframework-developer] MessageSource API functionality feedback

[Tony F. <ton...@ya...>]

One of the signatures of the overloads to the MessageSource interface will look like this:

        String getMessage(String code, Locale locale, Object args[], String defaultMessage);


Currently the code I have will substitute the args parameter into the message it finds from the associated MessageSource class's resolve function.  What it does not do, is substitute in the args into the defaultMessage param.  So the caller of this method must "fill in all the args" when they create the value to place within the defaultMessage.  Is this the behavior you'd like?  

My opinion is to have the method internally fill in the arg values for the user the same way.  (Also makes it easier for the developer to just copy and paste what they've put into the file that is storing the messages if they wish to pass it as a defaultMessage.)

RE: [Springframework-developer] Fwd: MessageSource

[Tony F. <ton...@ya...>]

Yes, an update of my copy of the code (and a merge with my changes corrected the problem).  Thank you.
 
 jürgen_höller_[werk3AT] <jue...@we...> wrote:Hi Tony,

I'm not sure what you mean regarding the MessageSource nesting. Actually, the code that you mention looks as follows:

if ((this.messageSource instanceof NestingMessageSource) && this.parent != null) {
((NestingMessageSource) messageSource).setParent(this.parent);
}

So the PARENT application context gets the PARENT of this context's message source, i.e. RB.parent = AppCtx.parent, AppCtx.messageSource = RB. I don't see a circular reference... Could you recheck and clarify this issue?

Working with 2 message resource bundles, one for my ApplicationContext and one for my ControllerServlet, works nicely - with keys in the latter bundle, with keys in the former bundle, and with keys that do not exist in any bundle.

Regards,
Juergen



-----Original Message-----
From: Tony Falabella [mailto:ton...@ya...] 
Sent: Friday, March 14, 2003 4:40 PM
To: spr...@li...
Subject: [Springframework-developer] Fwd: MessageSource


My changes are ready to integrate for the ErrorCoded stuff - please advise on how you'd like to coordinate it. (My preference would be to allow me to integrate and I will do as Juergen did, giving a high level description of what I did with each of the classes.)
I am however, now getting an error in one of the tests I wrote but never integrated for the ResourceMessageBundle, and it is a result of the change Juergen made to the ResouceBundleMessageSource. Juergen's change was to return a null if a MissingResourceException is thrown rather than throwing the an exception so that you traverse to the parent to try to resolve the msg. HIS CHANGE APPEARS TO BE CORRECT. However it appears to have uncovered another problem. 
When trying to resolve a message, I now get caught in an infininant loop. What I am seeing is the following:

I have 2 objects to deal with in the test I am running. The ResourceBundleMessageSource (call this RB) and the XMLWebApplicationContext. (AppCtx)

Upon startup, the AbstractApplicationContext.refresh() method gets called. Within it the ResourceBundleMessageSource bean is obtained from the factory. Then the following code is run:
if ((this.messageSource instanceof NestingMessageSource) && this.parent != null) {
( (NestingMessageSource) messageSource).setParent(this.messageSource);
}

Ultimately, what happens is that the we get a circular reference with, RB.parent = AppCtx, AppCtx.messageSource = RB. The resolver keeps going in a loop.
So I guess my first question is, what should the MessageSource's parent be, when it belongs to a Ctx? Should it be the Ctx itself, the Ctx parent, or the Ctx parent's MessageSource? (I haven't yet tested it, but I think it should be the Ctx parent's MessageSource).

Re: [Springframework-developer] mock objects

[Tony F. <ton...@ya...>]

I like the new naming you've come up with.  We are using a similar naming convention on a project I am currently on.  For us however, the "mock" package convention can be at various "levels" within the package structure.  For example we might have "com.interface21.web.mock" and "com.interface21.web.bind.mock".
 
 jürgen_höller_[werk3AT] <jue...@we...> wrote:Hi everybody,

I'm currently trying to integrate the basic mock objects from the test tree into the src tree, on the occasion of writing some test suites for an application project that uses Spring. The rationale behind this is that most of the mock objects are not just useful for Spring tests but also for application tests. This demands including them in the Spring distribution, and thus moving them to the main source tree. Besides, the "servletapi", "mo.ejb", and "jdbc" package names in the test tree aren't proper anyway.

My main need are the JNDI mocks that allow for building a JNDI tree with the application's environment, containing JDBC data sources and in our case Hibernate session factories - completely without any container. To achieve this, I've created a new SimpleDataSource mock that simply returns new connections on every getConnection call - which works nicely with Hibernate (BTW, in contrast to SingleConnectionDataSource that cannot handle standard Connection.close calls). TestDataSource is now in com.interface21.jdbc.core in the test tree, derived from SimpleDataSource.

Thus, I've moved the JNDI mocks to com.interface21.jndi.mock, and the JDBC mocks (SimpleDataSource and SingleConnectionDataSource) to com.interface21.jdbc.mock. Consequently, I've additionally moved the 2 EJB mocks to com.interface21.ejb.mock, and the Servlet mocks to com.interface21.web.mock. I don't use the latter 2 for application tests currently, but I might choose to do so sometime.

Of course, this step adds a few classes to the main source tree and to the distribution JARS, but that couple of KBs is hardly worth thinking about. I'd mainly like to know if anyone objects to moving these mock objects to the main source tree as a matter of principle, and if the new package names would be OK.

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
f. +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] mock objects

[Trevor C. <tc...@in...>]

Perfect.  Similiarly I created all my mock test objects in
com.interface21.jdbc.mock , so it sounds like it will stay compatible.

Rod, do we have a new clover jar available?  The current one is =
expired, and
I wanted to run coverage tests before submitting my jdbc tests (I =
emailed
you a few days ago, but may have messed up the address).

Trevor D. Cook


-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
Sent: March 14, 2003 1:53 PM
To: spr...@li...
Subject: [Springframework-developer] mock objects


Hi everybody,

I'm currently trying to integrate the basic mock objects from the test =
tree
into the src tree, on the occasion of writing some test suites for an
application project that uses Spring. The rationale behind this is that =
most
of the mock objects are not just useful for Spring tests but also for
application tests. This demands including them in the Spring =
distribution,
and thus moving them to the main source tree. Besides, the =
"servletapi",
"mo.ejb", and "jdbc" package names in the test tree aren't proper =
anyway.

My main need are the JNDI mocks that allow for building a JNDI tree =
with the
application's environment, containing JDBC data sources and in our case
Hibernate session factories - completely without any container. To =
achieve
this, I've created a new SimpleDataSource mock that simply returns new
connections on every getConnection call - which works nicely with =
Hibernate
(BTW, in contrast to SingleConnectionDataSource that cannot handle =
standard
Connection.close calls). TestDataSource is now in =
com.interface21.jdbc.core
in the test tree, derived from SimpleDataSource.

Thus, I've moved the JNDI mocks to com.interface21.jndi.mock, and the =
JDBC
mocks (SimpleDataSource and SingleConnectionDataSource) to
com.interface21.jdbc.mock. Consequently, I've additionally moved the 2 =
EJB
mocks to com.interface21.ejb.mock, and the Servlet mocks to
com.interface21.web.mock. I don't use the latter 2 for application =
tests
currently, but I might choose to do so sometime.

Of course, this step adds a few classes to the main source tree and to =
the
distribution JARS, but that couple of KBs is hardly worth thinking =
about.
I'd mainly like to know if anyone objects to moving these mock objects =
to
the main source tree as a matter of principle, and if the new package =
names
would be OK.

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
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!=20
Get cracking and register here for some mind boggling fun and=20
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 2/25/03
=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 2/25/03
=20

[Springframework-developer] mock objects

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

Hi everybody,

I'm currently trying to integrate the basic mock objects from the test =
tree into the src tree, on the occasion of writing some test suites for =
an application project that uses Spring. The rationale behind this is =
that most of the mock objects are not just useful for Spring tests but =
also for application tests. This demands including them in the Spring =
distribution, and thus moving them to the main source tree. Besides, the =
"servletapi", "mo.ejb", and "jdbc" package names in the test tree aren't =
proper anyway.

My main need are the JNDI mocks that allow for building a JNDI tree with =
the application's environment, containing JDBC data sources and in our =
case Hibernate session factories - completely without any container. To =
achieve this, I've created a new SimpleDataSource mock that simply =
returns new connections on every getConnection call - which works nicely =
with Hibernate (BTW, in contrast to SingleConnectionDataSource that =
cannot handle standard Connection.close calls). TestDataSource is now in =
com.interface21.jdbc.core in the test tree, derived from =
SimpleDataSource.

Thus, I've moved the JNDI mocks to com.interface21.jndi.mock, and the =
JDBC mocks (SimpleDataSource and SingleConnectionDataSource) to =
com.interface21.jdbc.mock. Consequently, I've additionally moved the 2 =
EJB mocks to com.interface21.ejb.mock, and the Servlet mocks to =
com.interface21.web.mock. I don't use the latter 2 for application tests =
currently, but I might choose to do so sometime.

Of course, this step adds a few classes to the main source tree and to =
the distribution JARS, but that couple of KBs is hardly worth thinking =
about. I'd mainly like to know if anyone objects to moving these mock =
objects to the main source tree as a matter of principle, and if the new =
package names would be OK.

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
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG

RE: [Springframework-developer] MessageSource

[Tony F. <ton...@ya...>]

I'll try them tonight.  Also, I will be committing some ResourceBundleMessageSourceTestSuite class when I integrate.  Hopefully we aren't duplicating efforts. 
I'll let you know know what I find. 
 jürgen_höller_[werk3AT] <jue...@we...> wrote: Actually, there weren't any MessageSource test cases around, not before and not after my changes. So I have just added some tests to AbstractApplicationContextTests/StaticApplicationContextTests/WebApplicationContextTests, and also some slight reworking of exception handling in AbstractNestingMessageSource and ResourceBundleMessageSource. It's already committed, please give it a try! On my installation, all tests pass.

BTW, I hope that everything compiles - I'm currently trying some name changes concerning the mock objects, but haven't committed them yet, so I had to commit very selectively.

Juergen


-----Original Message-----
From: Tony Falabella [mailto:ton...@ya...] 
Sent: Friday, March 14, 2003 5:16 PM
To: jürgen höller [werk3AT]; spr...@li...
Subject: RE: [Springframework-developer] MessageSource


Yes, you are correct about the line in the code (that was a mod I made to try to break the circular ref problem I was encountering). Perhaps it is my ResourceBundleTestSuite I constructed. 
Juergen, can you point me at a test case you have that does the nested msg source? The problem is only seen by me if it is not resolved in ANY context AND you did not pass in a defaultMessage. 
Thanks. 


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] MessageSource

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

Actually, there weren't any MessageSource test cases around, not before =
and not after my changes. So I have just added some tests to =
AbstractApplicationContextTests/StaticApplicationContextTests/WebApplicat=
ionContextTests, and also some slight reworking of exception handling in =
AbstractNestingMessageSource and ResourceBundleMessageSource. It's =
already committed, please give it a try! On my installation, all tests =
pass.

BTW, I hope that everything compiles - I'm currently trying some name =
changes concerning the mock objects, but haven't committed them yet, so =
I had to commit very selectively.

Juergen


-----Original Message-----
From: Tony Falabella [mailto:ton...@ya...]=20
Sent: Friday, March 14, 2003 5:16 PM
To: j=FCrgen h=F6ller [werk3AT]; =
spr...@li...
Subject: RE: [Springframework-developer] MessageSource


Yes, you are correct about the line in the code (that was a mod I made =
to try to break the circular ref problem I was encountering).  Perhaps =
it is my ResourceBundleTestSuite I constructed. =20
Juergen, can you point me at a test case you have that does the nested =
msg source?  The problem is only seen by me if it is not resolved in ANY =
context AND you did not pass in a defaultMessage.=20
Thanks.=20

RE: [Springframework-developer] MessageSource

[Tony F. <ton...@ya...>]

Yes, you are correct about the line in the code (that was a mod I made to try to break the circular ref problem I was encountering).  Perhaps it is my ResourceBundleTestSuite I constructed.  
Juergen, can you point me at a test case you have that does the nested msg source?  The problem is only seen by me if it is not resolved in ANY context AND you did not pass in a defaultMessage.
Thanks.
 jürgen_höller_[werk3AT] <jue...@we...> wrote:Hi Tony,

I'm not sure what you mean regarding the MessageSource nesting. Actually, the code that you mention looks as follows:

if ((this.messageSource instanceof NestingMessageSource) && this.parent != null) {
((NestingMessageSource) messageSource).setParent(this.parent);
}

So the PARENT application context gets the PARENT of this context's message source, i.e. RB.parent = AppCtx.parent, AppCtx.messageSource = RB. I don't see a circular reference... Could you recheck and clarify this issue?

Working with 2 message resource bundles, one for my ApplicationContext and one for my ControllerServlet, works nicely - with keys in the latter bundle, with keys in the former bundle, and with keys that do not exist in any bundle.

Regards,
Juergen



-----Original Message-----
From: Tony Falabella [mailto:ton...@ya...] 
Sent: Friday, March 14, 2003 4:40 PM
To: spr...@li...
Subject: [Springframework-developer] Fwd: MessageSource


My changes are ready to integrate for the ErrorCoded stuff - please advise on how you'd like to coordinate it. (My preference would be to allow me to integrate and I will do as Juergen did, giving a high level description of what I did with each of the classes.)
I am however, now getting an error in one of the tests I wrote but never integrated for the ResourceMessageBundle, and it is a result of the change Juergen made to the ResouceBundleMessageSource. Juergen's change was to return a null if a MissingResourceException is thrown rather than throwing the an exception so that you traverse to the parent to try to resolve the msg. HIS CHANGE APPEARS TO BE CORRECT. However it appears to have uncovered another problem. 
When trying to resolve a message, I now get caught in an infininant loop. What I am seeing is the following:

I have 2 objects to deal with in the test I am running. The ResourceBundleMessageSource (call this RB) and the XMLWebApplicationContext. (AppCtx)

Upon startup, the AbstractApplicationContext.refresh() method gets called. Within it the ResourceBundleMessageSource bean is obtained from the factory. Then the following code is run:
if ((this.messageSource instanceof NestingMessageSource) && this.parent != null) {
( (NestingMessageSource) messageSource).setParent(this.messageSource);
}

Ultimately, what happens is that the we get a circular reference with, RB.parent = AppCtx, AppCtx.messageSource = RB. The resolver keeps going in a loop.
So I guess my first question is, what should the MessageSource's parent be, when it belongs to a Ctx? Should it be the Ctx itself, the Ctx parent, or the Ctx parent's MessageSource? (I haven't yet tested it, but I think it should be the Ctx parent's MessageSource).

[Springframework-developer] Fwd: MessageSource

[Tony F. <ton...@ya...>]

My changes are ready to integrate for the ErrorCoded stuff - please advise on how you'd like to coordinate it.  (My preference would be to allow me to integrate and I will do as Juergen did, giving a high level description of what I did with each of the classes.)

I am however, now getting an error in one of the tests I wrote but never integrated for the ResourceMessageBundle, and it is a result of the change Juergen made to the ResouceBundleMessageSource.  Juergen's change was to return a null if a MissingResourceException is thrown rather than throwing the an exception so that you traverse to the parent to try to resolve the msg.  HIS CHANGE APPEARS TO BE CORRECT.  However it appears to have uncovered another problem.  

When trying to resolve a message,  I now get caught in an infininant loop.  What I am seeing is the following:
 
I have 2 objects to deal with in the test I am running.  The ResourceBundleMessageSource (call this RB) and the XMLWebApplicationContext. (AppCtx)
 

Upon startup, the AbstractApplicationContext.refresh() method gets called.  Within it the ResourceBundleMessageSource bean is obtained from the factory.  Then the following code is run:

  if ((this.messageSource instanceof NestingMessageSource) && this.parent != null) {
   ( (NestingMessageSource) messageSource).setParent(this.messageSource);
  }


Ultimately, what happens is that the we get a circular reference with, RB.parent = AppCtx, AppCtx.messageSource = RB.  The resolver keeps going in a loop.

So I guess my first question is, what should the MessageSource's parent be, when it belongs to a Ctx?  Should it be the Ctx itself, the Ctx parent, or the Ctx parent's MessageSource?  (I haven't yet tested it, but I think it should be the Ctx parent's MessageSource).