springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Update

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

Juergen,

Comments inline.

<jh>

I've just had a look at your AOP transaction support and the
PlatformTransactionManager. BTW, I agree that a true JtaTemplate object
makes sense, as there already is more than one property. And your separate
transaction exception hierarchy is fine too, although it currently lacks a
TransactionSystemException matching JTA's general SystemException.
</jh>
I misunderstood: I thought you meant to make the JtaTemplate static. So I
don't object quite so strongly to the use of statics as you've done.
However, I think there are still strong arguments against statics. We do
need a new general exception as you suggest, and we need to break down the
heuristic exceptions as suggested in my TODOs in the checked in code.

<jh>
- First of all, I suggested to change JndiServices into a static helper
class a while ago. I really don't see much value in JndiServices being a
true object, as I've already stated. JndiServices effectively just
simplifies context closing, there isn't great potential for extending it.
For example, DataSourceUtils is a static helper too, and it uses resp.
should use JndiServices... I don't mind true objects of course, it's just
that we need a consistent approach to decide between static helper utils and
true objects.
</jh>
I'm not a fan of static methods other than bootstrap methods, partly because
they're hard to test. My views have probably hardened on this since I wrote
the DataSourceUtils, although I think there are arguments for using statics
for such trivial things.

For example, if we have a static method relying on app server services such
as JTA, we can't easily unit test code that uses it, because we can't
replace that method by test code by overriding it or using a mock
implementation of any interface. If, on the other hand, we use an object or
an interface, it's possible to use mock implementations to verify that the
code under test correctly invokes the methods that would otherwise be
static. For example, I've easily been able to get to 80+% test coverage for
TransactionInterceptor because I can create mock implementations of the
PlatformTransactionManager interface that check that expectations are met
about how the TransactionInterceptor should use this.

I think that the ability to perform true unit testing in this way is very
important. Too often J2EE code is not properly unit tested, because things
can only be tested indirectly instead of testing just the behaviour of each
class in isolation. Otherwise we might have to get into having a whole mock
JNDI/JTA infrastructure, which could get very messy. The thing that finally
convinced me that EJB is not the way forward is that both infrastructure
code and app code written using it is very hard to test: I'm really keen to
move away from this.

<jh>
- Apropos consistency: I've currently got a JtaServices class that offer
static helpers for easy JTA access and implicit exception translation.
Furthermore, there's a JtaTemplate class analogous to JdbcTemplate that
allows for transactional execution via a callback. It uses JtaServices
internally. If JndiServices were a static helper too, then we could say that
XXXUtils and XXXServices were indicating static helpers while XXXTemplate
were true objects. Or should we adopt a different strategy?
</jh>
I agree with the proposed naming and I think it's important that the
XXXXTemplate is used consistently. My old JNDI stuff was inconsistent and
not completely mature (I haven't done much with it for months).

<jh>
- Regarding PlatformTransactionManager: While the concept is obvious, I'm
not entirely convinced whether it will ever be used beyond a JTA
implementation. How exactly do those container-specific things like
isolation level handling work? I assume they all use JTA, with some specific
tweaks. Generally, could there be a viable PlatformTransactionManager that
does not use JTA, especially for AOP? A JDBC-connection-based one will not
work - the (non-JTA) datasource isn't even fetched from JNDI when the method
call gets intercepted, and it's already returned to the pool on method call
end. To me, it seems that one needs to use JTA anyway for high-level
transaction management outside of the low-level resource-handling code. In
this case, the PlatformTransactionManager might abstract too much - it could
assume JTA and offer hooks for server-specific tweaking.
</jh>
In this case I think the more general solution isn't really more complex.
For example, we could have a TransactionTemplate with a JtaTemplate subclass
that set its PlatformTransactionManager property to use JTA. Also a
TransactionInterceptor that had a JtaTransactionInterceptor subclass that
did likewise.
My concern about tying ourselves to JTA is mainly isolation levels. These
are very important, but as far as I can see, many vendors don't expose this
directly except to EJBs--JTA doesn't seem to do the job--and then vendors
may expose it only to entity beans. We need the ability to get down and
dirty with their proprietary APIs so that implementations can really push
the buttons of each server. The most valuable implementation will probably
be a straight JTA one.

Also, there are a range of options such as UserTransaction, andTransaction
for how we might use app server transaction capabilities.

Does the PlatformTransactionManager API itself seem logical? If it doesn't
constrain us, I think it does add value. I don't think efficiency is a major
concern, as the cost of managing a transaction is far greater than that of
calling through an interface or creating an object.

<jh>
- A special issue: transaction propagation. We should support taking part in
transactions that already exist at interception/callback time, no matter
whether from Spring or direct JTA transaction handling. Currently,
JtaTemplate achieves this by explicitly checking for an existing transaction
and suppressing commit resp. just setting rollback-only accordingly. More
concretely, it has three propagation behavior strategies: "support existing"
(do not create new one), "create new if not existing" (default), "create new
 always" (nesting -> not supported by most JTA implementations).
</jh>
Agreed. The TransactionInterceptor is similar, taking naming from the EJB
spec so that it's easy for developers familiar with EJB to understand and
migrate to. It's crucial that we get this right, whichever way we go. We
should try to combine our efforts on this.

<jh>
- Concerning a common transaction infrastructure: Yep, absolutely - we need
a common approach. And it needs to be simple and easy to grasp, else we
don't gain much in comparison to direct JTA. So JtaTemplate should be based
on the same low-level code as TransactionInterceptor. This could be my
current JtaServices, your PlatformTransactionManager, or a JTA-based cousin
of it. To avoid duplicated work, I will stop working on JtaTemplate until we
have settled on a certain approach.
</jh>
OK. If we stick with PlatformTransactionManager it should probably move to
com.interface21.transaction, along with the exceptions.

I think we're working along very similar lines. You're JtaTemplate is very
close to what I envisaged when I wrote my first email about this last week.

Yann, what are your thoughts, as you were interested in transaction
management?

Regards,
Rod

RE: [Springframework-developer] Update

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

Rod,

It seems that the old AOP classes in com.interface21.aop are still in =
CVS. This package should be empty according to your new implementation, =
shouldn't it? Let's remove the old stuff to avoid confusion.

Juergen


> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]=20
> Sent: Sunday, March 23, 2003 1:50 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Update
>=20
>=20
> To prove I really am practising test first development these=20
> days, the test coverage on the aop.framework package is 95%.=20
> I am very keen that the overall test coverage should increase=20
> over time: it seems to be falling marginally.
>=20
> I'm still working on the aop.interceptor.transaction package,=20
> which was based on old code, so it will have comprehensive=20
> tests in a few days.
>=20
> Regards,
> Rod
>=20
> ----- Original Message -----
> From: "Rod Johnson" <rod...@in...>
> To: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>;=20
> <spr...@li...>
> Sent: Sunday, March 23, 2003 12:40 AM
> Subject: Re: [Springframework-developer] Update
>=20
>=20
> > All,
> >
> > I've now checked in my new AOP framework=20
> > (com.interface21.aop.framework), and the accompanying tests. The=20
> > org.aopalliance packages (binaries
> included
> > in /lib directory) are the APIs currently agreed by myself,=20
> Jon Tirsen=20
> > (Nanning Aspects) and Bob Lee (jAdvise) for interoperability. The=20
> > metadata attribute implementation is pluggable, but I'm planning to=20
> > use Attrib4j
> > (Sourceforge) and have been in touch with Mark Pollack, the=20
> author, who's
> > keen to help it meet our requirements.
> >
> > NB: The old AOP packages are gone: everyone please make sure they=20
> > don't
> have
> > the old sources hanging around.
> >
> > I've also checked in a com.interface21.aop.interceptor.transaction=20
> > package containing a generic CMT interceptor. The=20
> > PlatformTransactionManager is in this package: let me know if there=20
> > are any problems in the design of this interface.
> >
> >
> > Juergen,
> >
> > We're on the same track with the JTA callback approach you've=20
> > suggested,
> so
> > we should pool our efforts.
> >
> > My thoughts:
> >
> > - I don't like statics. For example, it's impossible to use a test
> subclass
> > overriding methods to check usage. So I'd prefer that it was a true
> object,
> > even if there's no state at this point. After all, the cost of tx
> management
> > is far greater than the cost of creating and destroying a small=20
> > object. Also, I think some state may come in (see below).=20
> For example,=20
> > your "allow no JTA" could be a bean property.
> > - My proposed callback interface (which I hadn't implemented yet)=20
> > returned
> a
> > boolean, indicating whether the tx should be committed or rollback.=20
> > I'm
> not
> > sure whether this is better than void, as it makes the interface=20
> > slightly harder to implement.
> > - I agree with your approach to exceptions and rollback.
> > - Do you intend to allow a setRollbackOnly mechanism or the=20
> like? My=20
> > AOP transaction interceptor has a TxControl class that allows this.=20
> > Maybe this class could be refactored into the common package. This=20
> > could be an alternative to the boolean return for enforcing=20
> rollback.=20
> > I'm not sure
> which
> > approach would be the best.
> > - I don't much like sharing the dao exceptions. I've checked in the=20
> > com.interface21.transaction package which contains my unchecked tx
> exception
> > hierarchy, which my tx interceptor uses. I'd prefer to=20
> standardize on
> this.
> >
> > I think the biggest questions are:
> >
> > - Do we want to try to refactor so that the new jta package=20
> shares the=20
> > TransactionControl and PlatformTransactionServices=20
> implementation from=20
> > my AOP transaction interceptor package? This would mean that the=20
> > callback wasn't JTA-specific, but could work with any=20
> > PlatformTransactionManager implementation. The common functionality=20
> > would be in the com.interface21.transaction package and multiple
> PlatformTransactionManager
> > implementations could be in packages such as=20
> > com.interface21.transaction.jta/wls/jboss etc.
> > - Is my PlatformTransactionManager interface adequate for=20
> this goal or=20
> > for how I'm trying to use it in the AOP stuff.
> >
> > Ideally it would be good if we pooled our efforts on a really good
> low-level
> > tx infrastructure, leaving the AOP interceptor as just a thin layer=20
> > over that.
> >
> > I think there's probably a bit more discussion to have before you=20
> > check in your callback mechanism.
> >
> > Regards,
> > Rod

RE: [Springframework-developer] Release?

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

Quoting from a previous mail of mine, with slight modifications:

<quote>
Finally, in terms of distribution: Should there be a separate examples =
download, or should they be included in the main download? Do we like to =
separate binary and source distribution (analogous to Tomcat), or offer =
a combined one (analogous to Log4J)? Do we include all the third-party =
libraries or just give respective download URLs? Or do we include all =
but specific larger ones that not everyone will need, like Velocity?

Personally, I tend to prefer a combined download for developers, =
including sources, third party libs, and Spring binaries (usable =
out-of-the-box for both application and framework development) - =
provided that it is of reasonable size (currently just ~1500 KB, without =
Velocity). Of course, it would make sense to offer a binary-only =
download too, with just the libraries needed for application development =
(i.e. no Clover, etc - currently ~650 KB, again without Velocity). So =
even with generated JavaDocs, some additional docs, and an example app, =
the combined download will probably not exceed 2 MB, and the binary =
download will clock in around 1 MB.

The only drawback is that users have to copy some framework and third =
party JARs to WEB-INF\lib if they want to run the example app, but this =
should be easy to document. Of course, we could go the Struts/WebWork =
way of providing preassembled WARs and EARs that duplicate all the =
libraries - but look at their distribution file sizes, ~20 MB/~17 MB for =
the zipped versions... I believe that Spring's distribution size should =
express Spring's general slimness and clearness, thus I vote for a =
"normalized" distribution.
</quote>

Juergen


> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]=20
> Sent: Sunday, March 23, 2003 5:09 AM
> To: spr...@li...
> Subject: [Springframework-developer] Release?
>=20
>=20
> Guys,
>=20
> As we had planned a release for late this month, what do you=20
> think we need to do to get 0.8 out? I think the biggest=20
> problems are probably some of the Javadoc, the lack of code=20
> examples and the lack of a tutorial.
>=20
> I think the AOP stuff, except the unfinished transaction=20
> interceptor, should probably go into a release. I think it=20
> can now make 1.0, and this is worth doing, because I've had a=20
> bit of time to spend on it in the last week.
>=20
> How should we structure the release? I remember there were=20
> some suggestions--were there any popular choices?
>=20
> Regards,
> Rod
>=20
> ____________________________________________________
> Rod Johnson
> J2EE Consultant and Author
> +44 7973 409 132
> rod...@in...
>=20
> Author of "Expert One-on-One J2EE Design and Development"=20
> (October 2002).=20
> http://www.amazon.com/exec/obidos/tg/detail/-/> 1861007841/
>=20
>=20
> Founder, Spring Framework:=20
> http://sourceforge.net/projects/springframework
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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:=20
> http://ads.sourceforge.net/cgi-> bin/redirect.pl?thaw0031en
>=20
>=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

RE: [Springframework-developer] Update

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

Hi Rod,

I've just had a look at your AOP transaction support and the =
PlatformTransactionManager. BTW, I agree that a true JtaTemplate object =
makes sense, as there already is more than one property. And your =
separate transaction exception hierarchy is fine too, although it =
currently lacks a TransactionSystemException matching JTA's general =
SystemException.

Now, some thoughts on the current state:

- First of all, I suggested to change JndiServices into a static helper =
class a while ago. I really don't see much value in JndiServices being a =
true object, as I've already stated. JndiServices effectively just =
simplifies context closing, there isn't great potential for extending =
it. For example, DataSourceUtils is a static helper too, and it uses =
resp. should use JndiServices... I don't mind true objects of course, =
it's just that we need a consistent approach to decide between static =
helper utils and true objects.

- Apropos consistency: I've currently got a JtaServices class that offer =
static helpers for easy JTA access and implicit exception translation. =
Furthermore, there's a JtaTemplate class analogous to JdbcTemplate that =
allows for transactional execution via a callback. It uses JtaServices =
internally. If JndiServices were a static helper too, then we could say =
that XXXUtils and XXXServices were indicating static helpers while =
XXXTemplate were true objects. Or should we adopt a different strategy?

- Regarding PlatformTransactionManager: While the concept is obvious, =
I'm not entirely convinced whether it will ever be used beyond a JTA =
implementation. How exactly do those container-specific things like =
isolation level handling work? I assume they all use JTA, with some =
specific tweaks. Generally, could there be a viable =
PlatformTransactionManager that does not use JTA, especially for AOP? A =
JDBC-connection-based one will not work - the (non-JTA) datasource isn't =
even fetched from JNDI when the method call gets intercepted, and it's =
already returned to the pool on method call end. To me, it seems that =
one needs to use JTA anyway for high-level transaction management =
outside of the low-level resource-handling code. In this case, the =
PlatformTransactionManager might abstract too much - it could assume JTA =
and offer hooks for server-specific tweaking.

- A special issue: transaction propagation. We should support taking =
part in transactions that already exist at interception/callback time, =
no matter whether from Spring or direct JTA transaction handling. =
Currently, JtaTemplate achieves this by explicitly checking for an =
existing transaction and suppressing commit resp. just setting =
rollback-only accordingly. More concretely, it has three propagation =
behavior strategies: "support existing" (do not create new one), "create =
new if not existing" (default), "create new always" (nesting -> not =
supported by most JTA implementations).

- Concerning a common transaction infrastructure: Yep, absolutely - we =
need a common approach. And it needs to be simple and easy to grasp, =
else we don't gain much in comparison to direct JTA. So JtaTemplate =
should be based on the same low-level code as TransactionInterceptor. =
This could be my current JtaServices, your PlatformTransactionManager, =
or a JTA-based cousin of it. To avoid duplicated work, I will stop =
working on JtaTemplate until we have settled on a certain approach.

Regards,
Juergen


> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]=20
> Sent: Sunday, March 23, 2003 1:41 AM
> To: j=FCrgen h=F6ller [werk3AT];=20
> spr...@li...
> Subject: Re: [Springframework-developer] Update
>=20
>=20
> All,
>=20
> I've now checked in my new AOP framework=20
> (com.interface21.aop.framework), and the accompanying tests.=20
> The org.aopalliance packages (binaries included in /lib=20
> directory) are the APIs currently agreed by myself, Jon=20
> Tirsen (Nanning Aspects) and Bob Lee (jAdvise) for=20
> interoperability. The metadata attribute implementation is=20
> pluggable, but I'm planning to use Attrib4j
> (Sourceforge) and have been in touch with Mark Pollack, the=20
> author, who's keen to help it meet our requirements.
>=20
> NB: The old AOP packages are gone: everyone please make sure=20
> they don't have the old sources hanging around.
>=20
> I've also checked in a=20
> com.interface21.aop.interceptor.transaction package=20
> containing a generic CMT interceptor. The=20
> PlatformTransactionManager is in this package: let me know if=20
> there are any problems in the design of this interface.
>=20
>=20
> Juergen,
>=20
> We're on the same track with the JTA callback approach you've=20
> suggested, so we should pool our efforts.
>=20
> My thoughts:
>=20
> - I don't like statics. For example, it's impossible to use a=20
> test subclass overriding methods to check usage. So I'd=20
> prefer that it was a true object, even if there's no state at=20
> this point. After all, the cost of tx management is far=20
> greater than the cost of creating and destroying a small=20
> object. Also, I think some state may come in (see below). For=20
> example, your "allow no JTA" could be a bean property.
> - My proposed callback interface (which I hadn't implemented=20
> yet) returned a boolean, indicating whether the tx should be=20
> committed or rollback. I'm not sure whether this is better=20
> than void, as it makes the interface slightly harder to implement.
> - I agree with your approach to exceptions and rollback.
> - Do you intend to allow a setRollbackOnly mechanism or the=20
> like? My AOP transaction interceptor has a TxControl class=20
> that allows this. Maybe this class could be refactored into=20
> the common package. This could be an alternative to the=20
> boolean return for enforcing rollback. I'm not sure which=20
> approach would be the best.
> - I don't much like sharing the dao exceptions. I've checked=20
> in the com.interface21.transaction package which contains my=20
> unchecked tx exception hierarchy, which my tx interceptor=20
> uses. I'd prefer to standardize on this.
>=20
> I think the biggest questions are:
>=20
> - Do we want to try to refactor so that the new jta package=20
> shares the TransactionControl and PlatformTransactionServices=20
> implementation from my AOP transaction interceptor package?=20
> This would mean that the callback wasn't JTA-specific, but=20
> could work with any PlatformTransactionManager=20
> implementation. The common functionality would be in the=20
> com.interface21.transaction package and multiple=20
> PlatformTransactionManager implementations could be in=20
> packages such as com.interface21.transaction.jta/wls/jboss etc.
> - Is my PlatformTransactionManager interface adequate for=20
> this goal or for how I'm trying to use it in the AOP stuff.
>=20
> Ideally it would be good if we pooled our efforts on a really=20
> good low-level tx infrastructure, leaving the AOP interceptor=20
> as just a thin layer over that.
>=20
> I think there's probably a bit more discussion to have before=20
> you check in your callback mechanism.
>=20
> Regards,
> Rod

[Springframework-developer] Data binding question

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

Hello everyone. I have a question about the Spring's data binding framework.
Let's say I have a simple bean with the String[] property like

public class ProgramRequest() {
   private String[] programs;
   public void setPrograms(String[] programs)...
   public String[] getPrograms()....
...
}  

And then I have HTML form with elements like this:

<select name="programs" id="programs" tabindex="2" multiple="multiple"
size="6" style="width:99%">
	<option value="1">Program 1</option>
	<option value="2">Program 2</option>
	<option value="3">Program 3</option>
</select>

I'd like to bind these multiple params onto String[] property of the bean
using the Spring's DataBinder:
...
ProgramRequest programRequest = new ProgramRequest();
ServletRequestDataBinder programRequestBinder =
			new ServletRequestDataBinder(programRequest,
"programRequest");
programRequestBinder.bind(request);

...

but it doesn't work (programs property is null after the bind() call).
However, manual binding does work:

programRequest.setPrograms(request.getParameterValues("programs"));


What am I missing?

Thanks,
Dmitriy.

[Springframework-developer] Re: [expertj2ee_with_rodjohnson] Retrieving clob problem

[Paul F. <pau...@ho...>]

Guys,

Is the question below really silly?  I have tried various approaches to the
problem mentioned without any success - the only thing that I haven't tried
is to have a method whereby I go back to pure jdbc and scrap the framework.
I don't want to do this.

An approach I did try was to use a stored procedure that takes in a varchar2
but I hit the maximum length when using large strings, which is why I need
clobs.  I am pretty sure that I need to use the character stream to write
the data - I am not sure how to set the auto commit to false before I call
the select for update then reset to true afterwards.

I hope this isn't too obvious - I have read and re-read the book.  I can see
ways I can solve this problem - I have a working solution in another
application - I just can't seem to get it to work within the framework.

Kind regards,

Paul Feaviour
p.s. I have cc'd the springframework as I am not sure if the wrox site is
still active.

----- Original Message -----
From: "Paul Feaviour" <pau...@ho...>
To: "ExpertJ2EE with RodJohnson" <exp...@p2...>
Sent: Friday, March 21, 2003 5:08 PM
Subject: [expertj2ee_with_rodjohnson] Retrieving clob problem


> Hi,
>
> I am trying to retrieve a clob for update using the following code:
>
>  class ClobQuery extends ManualExtractionSqlQuery {
>   public ClobQuery(DataSource ds) {
>    super(ds, "select my_clob from temp where id = ? for update");
>       declareParameter(new SqlParameter(Types.NUMERIC));
>    compile();
>   }
>
>   protected Object extract(ResultSet rs, int rownum) throws SQLException {
>      return ((OracleResultSet)rs).getCLOB(1);
>   }
>
> The calling method casts the single object in the returned list to an
oracle.sql.CLOB locator, which I then try and use to write data to the
database via the java.io.Writer returned via getCharacterOutputStream().
When I run this I get the following error:
>
> 1)
testClob(com.phoenix.business.support.test.BusinessDAOTester)com.interface21
.jdbc.core.UncategorizedSQLException: (JdbcTemplate.query(psc) with
PreparedStatementCreator
[PreparedStatementCreatorFactory.PreparedStatementCreatorImpl: sql={select
my_clob from temp where id = ? for update}: params={1}]): encountered
SQLException [ORA-01002: fetch out of sequence]; nested exception is:
java.sql.SQLException: ORA-01002: fetch out of sequence
> ...
>
> I am using 'for update' in my sql so the cursor should remain open?  I am
thinking that I need to setAutoCommit to false when making this call - I
don't see how I am able to do this?
>
> Having re-read page 356 of the book I am sure that what I am doing is at
least in the spirit of the data access classes - can anyone shed any
light/provide a solution to my problem?
>
> Thanks in advance.
>
> Paul Feaviour
>
> p.s. I am aware I am using non-portable code
>
> ---
> Change your mail options at http://p2p.wrox.com/manager.asp or
> to unsubscribe send a blank email to
lea...@p2....
>

[Springframework-developer] Release?

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

Guys,

As we had planned a release for late this month, what do you think we need
to do to get 0.8 out? I think the biggest problems are probably some of the
Javadoc, the lack of code examples and the lack of a tutorial.

I think the AOP stuff, except the unfinished transaction interceptor, should
probably go into a release. I think it can now make 1.0, and this is worth
doing, because I've had a bit of time to spend on it in the last week.

How should we structure the release? I remember there were some
suggestions--were there any popular choices?

Regards,
Rod

____________________________________________________
Rod Johnson
J2EE Consultant and Author
+44 7973 409 132
rod...@in...

Author of "Expert One-on-One J2EE Design and Development"
(October 2002).
http://www.amazon.com/exec/obidos/tg/detail/-/1861007841/

Founder, Spring Framework:
http://sourceforge.net/projects/springframework

Re: [Springframework-developer] Update

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

To prove I really am practising test first development these days, the test
coverage on the aop.framework package is 95%. I am very keen that the
overall test coverage should increase over time: it seems to be falling
marginally.

I'm still working on the aop.interceptor.transaction package, which was
based on old code, so it will have comprehensive tests in a few days.

Regards,
Rod

----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: "jürgen höller [werk3AT]" <jue...@we...>;
<spr...@li...>
Sent: Sunday, March 23, 2003 12:40 AM
Subject: Re: [Springframework-developer] Update


> All,
>
> I've now checked in my new AOP framework (com.interface21.aop.framework),
> and the accompanying tests. The org.aopalliance packages (binaries
included
> in /lib directory) are the APIs currently agreed by myself, Jon Tirsen
> (Nanning Aspects) and Bob Lee (jAdvise) for interoperability. The metadata
> attribute implementation is pluggable, but I'm planning to use Attrib4j
> (Sourceforge) and have been in touch with Mark Pollack, the author, who's
> keen to help it meet our requirements.
>
> NB: The old AOP packages are gone: everyone please make sure they don't
have
> the old sources hanging around.
>
> I've also checked in a com.interface21.aop.interceptor.transaction package
> containing a generic CMT interceptor. The PlatformTransactionManager is in
> this package: let me know if there are any problems in the design of this
> interface.
>
>
> Juergen,
>
> We're on the same track with the JTA callback approach you've suggested,
so
> we should pool our efforts.
>
> My thoughts:
>
> - I don't like statics. For example, it's impossible to use a test
subclass
> overriding methods to check usage. So I'd prefer that it was a true
object,
> even if there's no state at this point. After all, the cost of tx
management
> is far greater than the cost of creating and destroying a small object.
> Also, I think some state may come in (see below). For example, your "allow
> no JTA" could be a bean property.
> - My proposed callback interface (which I hadn't implemented yet) returned
a
> boolean, indicating whether the tx should be committed or rollback. I'm
not
> sure whether this is better than void, as it makes the interface slightly
> harder to implement.
> - I agree with your approach to exceptions and rollback.
> - Do you intend to allow a setRollbackOnly mechanism or the like? My AOP
> transaction interceptor has a TxControl class that allows this. Maybe this
> class could be refactored into the common package. This could be an
> alternative to the boolean return for enforcing rollback. I'm not sure
which
> approach would be the best.
> - I don't much like sharing the dao exceptions. I've checked in the
> com.interface21.transaction package which contains my unchecked tx
exception
> hierarchy, which my tx interceptor uses. I'd prefer to standardize on
this.
>
> I think the biggest questions are:
>
> - Do we want to try to refactor so that the new jta package shares the
> TransactionControl and PlatformTransactionServices implementation from my
> AOP transaction interceptor package? This would mean that the callback
> wasn't JTA-specific, but could work with any PlatformTransactionManager
> implementation. The common functionality would be in the
> com.interface21.transaction package and multiple
PlatformTransactionManager
> implementations could be in packages such as
> com.interface21.transaction.jta/wls/jboss etc.
> - Is my PlatformTransactionManager interface adequate for this goal or for
> how I'm trying to use it in the AOP stuff.
>
> Ideally it would be good if we pooled our efforts on a really good
low-level
> tx infrastructure, leaving the AOP interceptor as just a thin layer over
> that.
>
> I think there's probably a bit more discussion to have before you check in
> your callback mechanism.
>
> Regards,
> Rod
>
> ----- Original Message -----
> From: "jürgen höller [werk3AT]" <jue...@we...>
> To: <spr...@li...>
> Sent: Thursday, March 20, 2003 8:49 AM
> 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=true. 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
> >
> >
> > 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
> >
> >
> >
> > -------------------------------------------------------
> > 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.
> > 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
> >
>
>
> -------------------------------------------------------
> 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
>
>
>
>
> -------------------------------------------------------
> 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] Update

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

All,

I've now checked in my new AOP framework (com.interface21.aop.framework),
and the accompanying tests. The org.aopalliance packages (binaries included
in /lib directory) are the APIs currently agreed by myself, Jon Tirsen
(Nanning Aspects) and Bob Lee (jAdvise) for interoperability. The metadata
attribute implementation is pluggable, but I'm planning to use Attrib4j
(Sourceforge) and have been in touch with Mark Pollack, the author, who's
keen to help it meet our requirements.

NB: The old AOP packages are gone: everyone please make sure they don't have
the old sources hanging around.

I've also checked in a com.interface21.aop.interceptor.transaction package
containing a generic CMT interceptor. The PlatformTransactionManager is in
this package: let me know if there are any problems in the design of this
interface.


Juergen,

We're on the same track with the JTA callback approach you've suggested, so
we should pool our efforts.

My thoughts:

- I don't like statics. For example, it's impossible to use a test subclass
overriding methods to check usage. So I'd prefer that it was a true object,
even if there's no state at this point. After all, the cost of tx management
is far greater than the cost of creating and destroying a small object.
Also, I think some state may come in (see below). For example, your "allow
no JTA" could be a bean property.
- My proposed callback interface (which I hadn't implemented yet) returned a
boolean, indicating whether the tx should be committed or rollback. I'm not
sure whether this is better than void, as it makes the interface slightly
harder to implement.
- I agree with your approach to exceptions and rollback.
- Do you intend to allow a setRollbackOnly mechanism or the like? My AOP
transaction interceptor has a TxControl class that allows this. Maybe this
class could be refactored into the common package. This could be an
alternative to the boolean return for enforcing rollback. I'm not sure which
approach would be the best.
- I don't much like sharing the dao exceptions. I've checked in the
com.interface21.transaction package which contains my unchecked tx exception
hierarchy, which my tx interceptor uses. I'd prefer to standardize on this.

I think the biggest questions are:

- Do we want to try to refactor so that the new jta package shares the
TransactionControl and PlatformTransactionServices implementation from my
AOP transaction interceptor package? This would mean that the callback
wasn't JTA-specific, but could work with any PlatformTransactionManager
implementation. The common functionality would be in the
com.interface21.transaction package and multiple PlatformTransactionManager
implementations could be in packages such as
com.interface21.transaction.jta/wls/jboss etc.
- Is my PlatformTransactionManager interface adequate for this goal or for
how I'm trying to use it in the AOP stuff.

Ideally it would be good if we pooled our efforts on a really good low-level
tx infrastructure, leaving the AOP interceptor as just a thin layer over
that.

I think there's probably a bit more discussion to have before you check in
your callback mechanism.

Regards,
Rod

----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, March 20, 2003 8:49 AM
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=true. 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
>
>
> 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
>
>
>
> -------------------------------------------------------
> 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.
> 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
>


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

Re: [Springframework-developer] Problems at Wrox

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

Tim,

All this is unclear right now. The chances of me receiving a cent of royalty
from sales so far are remote, so I'd say you haven't put any money in my
pocket :-( Thanks for buying the copies, though!

As far as I can tell, the book is in its second print run now, so there
should be a few thousand copies left to be sold. It continues to sell well.

The good news is that I have been approached by several publishers
interested in picking up the rights to Expert 1:1 and signing me up for
further writing. So I think the book will be reprinted, probably by another
publisher, and will continue to be available. Hopefully I'll get higher
royalties for subsequent sales, as I'll own the IP.

Regards,
Rod

----- Original Message -----
From: "Tim McNerney" <mu...@on...>
To: <spr...@li...>
Sent: Friday, March 21, 2003 5:42 PM
Subject: [Springframework-developer] Problems at Wrox


> 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

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.