springframework-developer — Spring Framework developers list

[Springframework-developer] build file

[Isabelle M. <met...@pa...>]

Hi everyone,

Can I set failonerror to true in the build file, otherwise the full target will build the jar file if the compile fails.

Isabelle

-- 
Isabelle Muszynski
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89

Re: [Springframework-developer] UML

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

Maybe we could export JPEGS or GIFs and include them in the Javadoc
package.html files. That would be great!

Rod

----- Original Message -----
From: "Isabelle Muszynski" <met...@pa...>
To: <spr...@li...>
Sent: Thursday, April 03, 2003 2:52 PM
Subject: [Springframework-developer] UML


> Hi everyone,
>
> I'm also producing some UML diagrams for Spring, for the project I'm
working on. Might be good to inlcude these in the cvs tree as well. I'm
using MagicDraw, maybe we can get a free licence from them
(www.magicdraw.com).
>
> Isabelle
>
> --
> Isabelle Muszynski
> Zandweellaan 4
> 2660 Antwerpen
> Belgium
> Tel. 32-(0)3-830 18 54
> Mobile: 32-(0)485 49 50 89
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] onCompileInternal

[Isabelle M. <met...@pa...>]

Hi everyone,

I've uploaded a couple of files in the bug tracking system to fix the params parsing problem in SqlOperation.

Isabelle

-- 
Isabelle Muszynski
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89

RE: [Springframework-developer] Transaction support

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

"examples" dir in the "main" module sounds good to me.
+1 on this.

Dmitriy.

-----Original Message-----
From: William G. Thompson, Jr. [mailto:wg...@rc...]
Sent: Thursday, April 03, 2003 09:51 AM
To: spring-dev-list
Subject: Re: [Springframework-developer] Transaction support


Speaking of project docs... Apache Forrest is starting to look good for =

xml based project docs.  http://xml.apache.org/forrest/index.html

+1 for the seperate source dirs.

later.
Bill

j=FCrgen h=F6ller [werk3AT] wrote:
> Maybe it would be easier to handle if we simply added an additional =
source
directory "examples" besides "src" and "test", containing the packages =
you
propose? I don't see a need for a separate CVS module for "core =
examples",
although there are arguments for it.
>=20
> Rod, where do you intend to put the adapted example app from the =
book?
>=20
> Another issue is where to put misc docs, but I consider the "docs"
directory used by the javadoc Ant task (it uses "docs/api", more
specifically) an appropriate location. We will probably need to =
restructure
the (non-API) docs when they become more organized anyway.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: Kopylenko, Dmitry [mailto:dko...@ac...]
> Sent: Thursday, April 03, 2003 3:11 PM
> To: j=FCrgen h=F6ller [werk3AT]; spring-dev-list
> Subject: RE: [Springframework-developer] Transaction support
>=20
>=20
> How about "Spring/examples" tree on CVS HEAD with package structure
somewhat
> like this: com.interface21.sample.<sample_module_name>.<sub_packages> =
?
>=20
> -----Original Message-----
> From: j=FCrgen h=F6ller [werk3AT] =
[mailto:jue...@we...]
> Sent: Thursday, April 03, 2003 07:57 AM
> To: spring-dev-list
> Subject: RE: [Springframework-developer] Transaction support
>=20
>=20
> Dmitriy, everybody,
>=20
> Well, sample apps and usage docs would help a lot, of course. I'm =
willing
to
> put effort into these as soon as we decide to settle on the current =
design
> of the transaction support.
>=20
> I'm not sure where to put these resources, though. Tx support
documentation
> could go into the package JavaDocs of the transaction package, this =
would
be
> a natural fit. But where should we put example classes? Hibernate =
puts
them
> in its net.sf.hibernate.eg package, but I'm not sure if it is a
particulary
> good idea to put examples in the main source tree. What do you think?
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: Kopylenko, Dmitry [mailto:dko...@ac...]
> Sent: Thursday, April 03, 2003 2:50 PM
> To: j=FCrgen h=F6ller [werk3AT]
> Cc: 'spring-dev-list'
> Subject: RE: [Springframework-developer] Transaction support
>=20
>=20
> Juergen, guys,
> are you planning any sample apps/detailed usage docs (on transaction
support
> for example) for 0.8 release?
>=20
> Rod,=20
> when do you think the aopalliance.org will be up and running?
>=20
> Thanks.
>=20
> Dmitriy.
>=20
> -----Original Message-----
> From: j=FCrgen h=F6ller [werk3AT] =
[mailto:jue...@we...]
> Sent: Thursday, April 03, 2003 07:39 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Transaction support
>=20
>=20
> Rod,
>=20
> I guess removing the check in TransactionInterceptor and modifying =
the
test
> case accordingly will solve the issue.
>=20
> Now that we seem to approach a certain degree of stability in terms =
of
> transaction support too, we should actively consider releasing 0.8. =
We're
> not really following "release early, release often" up to now...
>=20
> A combined developer download will be enough for the moment, I =
assume, we
> don't really need a binary-only download before 1.0. Have you looked =
at
how
> SourceForge's release support works already? It shouldn't be hard to
figure
> out.
>=20
> Even for 0.8, we should try to raise some attention just after the
release,
> for example at TheServerSide. We could gain important feedback, long
enough
> before 1.0 to be able to still tweak the design if necessary.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Thursday, April 03, 2003 2:27 PM
> To: j=FCrgen h=F6ller [werk3AT];
> spr...@li...
> Subject: Re: [Springframework-developer] Transaction support
>=20
>=20
> Juergen,
>=20
> I needed to put that check in to get the tests to pass. However, the
> clarification about how PlatformTransactionManager implementations =
should
> behave would also resolve the problem (meaning I could modify the =
test
case,
> not the class).
>=20
> I haven't looked at your code in great detail, but from what I've =
seen it
> looks good and I endorse the design.
>=20
> Regards,
> Rod
>=20
>=20
> Hi Rod,
>=20
> I've just seen your modifications to TransactionInterceptor. You've =
added
> explicit programmatic rollback handling, i.e.
>=20
> if (status !=3D null && !status.isRollbackOnly()) {
> // Normal course of transaction: commit
> doCommit();
> }
> else {
> // Handle programmatic rollback
> doRollback();
> }
>=20
> where doCommit and doRollback call PlatformTransactionManager's =
commit and
> rollback, respectively. Technically, this isn't necessary, as the
> PlatformTransactionManager implementation is supposed to handle this. =
That
> way, every transaction manager client can benefit from it implicitly.
> Unfortunately, PlatformTransactionManager's documentation currently
doesn't
> state that, so I will add appropriate JavaDoc.
>=20
> By deriving from AbstractPlatformTransactionManager instead of
implementing
> PlatformTransactionManager directly, a transaction manager =
implementation
> can benefit from the former's programmatic rollback and propagation
behavior
> handling. A subclass just needs to implement doCommit, doRollback, =
etc
> without having to care about such case handling that will normally be =
the
> same (see JtaTransactionManager).
>=20
> All things considered, I suggest to remove the explicit check above =
if you
> don't mind, as it is unnecessary.
>=20
> Generally, what do you think of the current state of the transaction
> support? Any limitations or inappropriate design decisions?
>=20
>=20




-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:=20
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Transaction support

[William G. T. Jr. <wg...@rc...>]

Speaking of project docs... Apache Forrest is starting to look good for 
xml based project docs.  http://xml.apache.org/forrest/index.html

+1 for the seperate source dirs.

later.
Bill

jürgen höller [werk3AT] wrote:
> Maybe it would be easier to handle if we simply added an additional source directory "examples" besides "src" and "test", containing the packages you propose? I don't see a need for a separate CVS module for "core examples", although there are arguments for it.
> 
> Rod, where do you intend to put the adapted example app from the book?
> 
> Another issue is where to put misc docs, but I consider the "docs" directory used by the javadoc Ant task (it uses "docs/api", more specifically) an appropriate location. We will probably need to restructure the (non-API) docs when they become more organized anyway.
> 
> Juergen
> 
> 
> -----Original Message-----
> From: Kopylenko, Dmitry [mailto:dko...@ac...]
> Sent: Thursday, April 03, 2003 3:11 PM
> To: jürgen höller [werk3AT]; spring-dev-list
> Subject: RE: [Springframework-developer] Transaction support
> 
> 
> How about "Spring/examples" tree on CVS HEAD with package structure somewhat
> like this: com.interface21.sample.<sample_module_name>.<sub_packages> ?
> 
> -----Original Message-----
> From: jürgen höller [werk3AT] [mailto:jue...@we...]
> Sent: Thursday, April 03, 2003 07:57 AM
> To: spring-dev-list
> Subject: RE: [Springframework-developer] Transaction support
> 
> 
> Dmitriy, everybody,
> 
> Well, sample apps and usage docs would help a lot, of course. I'm willing to
> put effort into these as soon as we decide to settle on the current design
> of the transaction support.
> 
> I'm not sure where to put these resources, though. Tx support documentation
> could go into the package JavaDocs of the transaction package, this would be
> a natural fit. But where should we put example classes? Hibernate puts them
> in its net.sf.hibernate.eg package, but I'm not sure if it is a particulary
> good idea to put examples in the main source tree. What do you think?
> 
> Juergen
> 
> 
> -----Original Message-----
> From: Kopylenko, Dmitry [mailto:dko...@ac...]
> Sent: Thursday, April 03, 2003 2:50 PM
> To: jürgen höller [werk3AT]
> Cc: 'spring-dev-list'
> Subject: RE: [Springframework-developer] Transaction support
> 
> 
> Juergen, guys,
> are you planning any sample apps/detailed usage docs (on transaction support
> for example) for 0.8 release?
> 
> Rod, 
> when do you think the aopalliance.org will be up and running?
> 
> Thanks.
> 
> Dmitriy.
> 
> -----Original Message-----
> From: jürgen höller [werk3AT] [mailto:jue...@we...]
> Sent: Thursday, April 03, 2003 07:39 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Transaction support
> 
> 
> Rod,
> 
> I guess removing the check in TransactionInterceptor and modifying the test
> case accordingly will solve the issue.
> 
> Now that we seem to approach a certain degree of stability in terms of
> transaction support too, we should actively consider releasing 0.8. We're
> not really following "release early, release often" up to now...
> 
> A combined developer download will be enough for the moment, I assume, we
> don't really need a binary-only download before 1.0. Have you looked at how
> SourceForge's release support works already? It shouldn't be hard to figure
> out.
> 
> Even for 0.8, we should try to raise some attention just after the release,
> for example at TheServerSide. We could gain important feedback, long enough
> before 1.0 to be able to still tweak the design if necessary.
> 
> Juergen
> 
> 
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Thursday, April 03, 2003 2:27 PM
> To: jürgen höller [werk3AT];
> spr...@li...
> Subject: Re: [Springframework-developer] Transaction support
> 
> 
> Juergen,
> 
> I needed to put that check in to get the tests to pass. However, the
> clarification about how PlatformTransactionManager implementations should
> behave would also resolve the problem (meaning I could modify the test case,
> not the class).
> 
> I haven't looked at your code in great detail, but from what I've seen it
> looks good and I endorse the design.
> 
> Regards,
> Rod
> 
> 
> Hi Rod,
> 
> I've just seen your modifications to TransactionInterceptor. You've added
> explicit programmatic rollback handling, i.e.
> 
> if (status != null && !status.isRollbackOnly()) {
> // Normal course of transaction: commit
> doCommit();
> }
> else {
> // Handle programmatic rollback
> doRollback();
> }
> 
> where doCommit and doRollback call PlatformTransactionManager's commit and
> rollback, respectively. Technically, this isn't necessary, as the
> PlatformTransactionManager implementation is supposed to handle this. That
> way, every transaction manager client can benefit from it implicitly.
> Unfortunately, PlatformTransactionManager's documentation currently doesn't
> state that, so I will add appropriate JavaDoc.
> 
> By deriving from AbstractPlatformTransactionManager instead of implementing
> PlatformTransactionManager directly, a transaction manager implementation
> can benefit from the former's programmatic rollback and propagation behavior
> handling. A subclass just needs to implement doCommit, doRollback, etc
> without having to care about such case handling that will normally be the
> same (see JtaTransactionManager).
> 
> All things considered, I suggest to remove the explicit check above if you
> don't mind, as it is unnecessary.
> 
> Generally, what do you think of the current state of the transaction
> support? Any limitations or inappropriate design decisions?
> 
> 

[Springframework-developer] Parameter placeholders in SqlOperation

[Isabelle M. <met...@pa...>]

Hi everyone,

I've moved this bug to highest priority, but will provide the fix shortly.
It concerns method compileInternal.

Isabelle

-- 
Isabelle Muszynski
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89

[Springframework-developer] UML

[Isabelle M. <met...@pa...>]

Hi everyone,

I'm also producing some UML diagrams for Spring, for the project I'm working on. Might be good to inlcude these in the cvs tree as well. I'm using MagicDraw, maybe we can get a free licence from them (www.magicdraw.com).

Isabelle

-- 
Isabelle Muszynski
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89

[Springframework-developer] Javadocs

[Isabelle M. <met...@pa...>]

Concerning the style, I suggest picking the style currently used most ("command style" as Juergen calls it" and making sure everything is consistent.

Isabelle

-- 
Isabelle Muszynski
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89

RE: [Springframework-developer] Transaction support

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

Maybe it would be easier to handle if we simply added an additional =
source directory "examples" besides "src" and "test", containing the =
packages you propose? I don't see a need for a separate CVS module for =
"core examples", although there are arguments for it.

Rod, where do you intend to put the adapted example app from the book?

Another issue is where to put misc docs, but I consider the "docs" =
directory used by the javadoc Ant task (it uses "docs/api", more =
specifically) an appropriate location. We will probably need to =
restructure the (non-API) docs when they become more organized anyway.

Juergen


-----Original Message-----
From: Kopylenko, Dmitry [mailto:dko...@ac...]
Sent: Thursday, April 03, 2003 3:11 PM
To: j=FCrgen h=F6ller [werk3AT]; spring-dev-list
Subject: RE: [Springframework-developer] Transaction support


How about "Spring/examples" tree on CVS HEAD with package structure =
somewhat
like this: com.interface21.sample.<sample_module_name>.<sub_packages> ?

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
Sent: Thursday, April 03, 2003 07:57 AM
To: spring-dev-list
Subject: RE: [Springframework-developer] Transaction support


Dmitriy, everybody,

Well, sample apps and usage docs would help a lot, of course. I'm =
willing to
put effort into these as soon as we decide to settle on the current =
design
of the transaction support.

I'm not sure where to put these resources, though. Tx support =
documentation
could go into the package JavaDocs of the transaction package, this =
would be
a natural fit. But where should we put example classes? Hibernate puts =
them
in its net.sf.hibernate.eg package, but I'm not sure if it is a =
particulary
good idea to put examples in the main source tree. What do you think?

Juergen


-----Original Message-----
From: Kopylenko, Dmitry [mailto:dko...@ac...]
Sent: Thursday, April 03, 2003 2:50 PM
To: j=FCrgen h=F6ller [werk3AT]
Cc: 'spring-dev-list'
Subject: RE: [Springframework-developer] Transaction support


Juergen, guys,
are you planning any sample apps/detailed usage docs (on transaction =
support
for example) for 0.8 release?

Rod,=20
when do you think the aopalliance.org will be up and running?

Thanks.

Dmitriy.

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
Sent: Thursday, April 03, 2003 07:39 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Transaction support


Rod,

I guess removing the check in TransactionInterceptor and modifying the =
test
case accordingly will solve the issue.

Now that we seem to approach a certain degree of stability in terms of
transaction support too, we should actively consider releasing 0.8. =
We're
not really following "release early, release often" up to now...

A combined developer download will be enough for the moment, I assume, =
we
don't really need a binary-only download before 1.0. Have you looked at =
how
SourceForge's release support works already? It shouldn't be hard to =
figure
out.

Even for 0.8, we should try to raise some attention just after the =
release,
for example at TheServerSide. We could gain important feedback, long =
enough
before 1.0 to be able to still tweak the design if necessary.

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Thursday, April 03, 2003 2:27 PM
To: j=FCrgen h=F6ller [werk3AT];
spr...@li...
Subject: Re: [Springframework-developer] Transaction support


Juergen,

I needed to put that check in to get the tests to pass. However, the
clarification about how PlatformTransactionManager implementations =
should
behave would also resolve the problem (meaning I could modify the test =
case,
not the class).

I haven't looked at your code in great detail, but from what I've seen =
it
looks good and I endorse the design.

Regards,
Rod


Hi Rod,

I've just seen your modifications to TransactionInterceptor. You've =
added
explicit programmatic rollback handling, i.e.

if (status !=3D null && !status.isRollbackOnly()) {
// Normal course of transaction: commit
doCommit();
}
else {
// Handle programmatic rollback
doRollback();
}

where doCommit and doRollback call PlatformTransactionManager's commit =
and
rollback, respectively. Technically, this isn't necessary, as the
PlatformTransactionManager implementation is supposed to handle this. =
That
way, every transaction manager client can benefit from it implicitly.
Unfortunately, PlatformTransactionManager's documentation currently =
doesn't
state that, so I will add appropriate JavaDoc.

By deriving from AbstractPlatformTransactionManager instead of =
implementing
PlatformTransactionManager directly, a transaction manager =
implementation
can benefit from the former's programmatic rollback and propagation =
behavior
handling. A subclass just needs to implement doCommit, doRollback, etc
without having to care about such case handling that will normally be =
the
same (see JtaTransactionManager).

All things considered, I suggest to remove the explicit check above if =
you
don't mind, as it is unnecessary.

Generally, what do you think of the current state of the transaction
support? Any limitations or inappropriate design decisions?






-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:=20
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:=20
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Transaction support

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

How about "Spring/examples" tree on CVS HEAD with package structure =
somewhat
like this: com.interface21.sample.<sample_module_name>.<sub_packages> ?

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
Sent: Thursday, April 03, 2003 07:57 AM
To: spring-dev-list
Subject: RE: [Springframework-developer] Transaction support


Dmitriy, everybody,

Well, sample apps and usage docs would help a lot, of course. I'm =
willing to
put effort into these as soon as we decide to settle on the current =
design
of the transaction support.

I'm not sure where to put these resources, though. Tx support =
documentation
could go into the package JavaDocs of the transaction package, this =
would be
a natural fit. But where should we put example classes? Hibernate puts =
them
in its net.sf.hibernate.eg package, but I'm not sure if it is a =
particulary
good idea to put examples in the main source tree. What do you think?

Juergen


-----Original Message-----
From: Kopylenko, Dmitry [mailto:dko...@ac...]
Sent: Thursday, April 03, 2003 2:50 PM
To: j=FCrgen h=F6ller [werk3AT]
Cc: 'spring-dev-list'
Subject: RE: [Springframework-developer] Transaction support


Juergen, guys,
are you planning any sample apps/detailed usage docs (on transaction =
support
for example) for 0.8 release?

Rod,=20
when do you think the aopalliance.org will be up and running?

Thanks.

Dmitriy.

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
Sent: Thursday, April 03, 2003 07:39 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Transaction support


Rod,

I guess removing the check in TransactionInterceptor and modifying the =
test
case accordingly will solve the issue.

Now that we seem to approach a certain degree of stability in terms of
transaction support too, we should actively consider releasing 0.8. =
We're
not really following "release early, release often" up to now...

A combined developer download will be enough for the moment, I assume, =
we
don't really need a binary-only download before 1.0. Have you looked at =
how
SourceForge's release support works already? It shouldn't be hard to =
figure
out.

Even for 0.8, we should try to raise some attention just after the =
release,
for example at TheServerSide. We could gain important feedback, long =
enough
before 1.0 to be able to still tweak the design if necessary.

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Thursday, April 03, 2003 2:27 PM
To: j=FCrgen h=F6ller [werk3AT];
spr...@li...
Subject: Re: [Springframework-developer] Transaction support


Juergen,

I needed to put that check in to get the tests to pass. However, the
clarification about how PlatformTransactionManager implementations =
should
behave would also resolve the problem (meaning I could modify the test =
case,
not the class).

I haven't looked at your code in great detail, but from what I've seen =
it
looks good and I endorse the design.

Regards,
Rod


Hi Rod,

I've just seen your modifications to TransactionInterceptor. You've =
added
explicit programmatic rollback handling, i.e.

if (status !=3D null && !status.isRollbackOnly()) {
// Normal course of transaction: commit
doCommit();
}
else {
// Handle programmatic rollback
doRollback();
}

where doCommit and doRollback call PlatformTransactionManager's commit =
and
rollback, respectively. Technically, this isn't necessary, as the
PlatformTransactionManager implementation is supposed to handle this. =
That
way, every transaction manager client can benefit from it implicitly.
Unfortunately, PlatformTransactionManager's documentation currently =
doesn't
state that, so I will add appropriate JavaDoc.

By deriving from AbstractPlatformTransactionManager instead of =
implementing
PlatformTransactionManager directly, a transaction manager =
implementation
can benefit from the former's programmatic rollback and propagation =
behavior
handling. A subclass just needs to implement doCommit, doRollback, etc
without having to care about such case handling that will normally be =
the
same (see JtaTransactionManager).

All things considered, I suggest to remove the explicit check above if =
you
don't mind, as it is unnecessary.

Generally, what do you think of the current state of the transaction
support? Any limitations or inappropriate design decisions?






-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:=20
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:=20
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Transaction support

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

Dmitriy, everybody,

Well, sample apps and usage docs would help a lot, of course. I'm =
willing to put effort into these as soon as we decide to settle on the =
current design of the transaction support.

I'm not sure where to put these resources, though. Tx support =
documentation could go into the package JavaDocs of the transaction =
package, this would be a natural fit. But where should we put example =
classes? Hibernate puts them in its net.sf.hibernate.eg package, but I'm =
not sure if it is a particulary good idea to put examples in the main =
source tree. What do you think?

Juergen


-----Original Message-----
From: Kopylenko, Dmitry [mailto:dko...@ac...]
Sent: Thursday, April 03, 2003 2:50 PM
To: j=FCrgen h=F6ller [werk3AT]
Cc: 'spring-dev-list'
Subject: RE: [Springframework-developer] Transaction support


Juergen, guys,
are you planning any sample apps/detailed usage docs (on transaction =
support
for example) for 0.8 release?

Rod,=20
when do you think the aopalliance.org will be up and running?

Thanks.

Dmitriy.

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
Sent: Thursday, April 03, 2003 07:39 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Transaction support


Rod,

I guess removing the check in TransactionInterceptor and modifying the =
test
case accordingly will solve the issue.

Now that we seem to approach a certain degree of stability in terms of
transaction support too, we should actively consider releasing 0.8. =
We're
not really following "release early, release often" up to now...

A combined developer download will be enough for the moment, I assume, =
we
don't really need a binary-only download before 1.0. Have you looked at =
how
SourceForge's release support works already? It shouldn't be hard to =
figure
out.

Even for 0.8, we should try to raise some attention just after the =
release,
for example at TheServerSide. We could gain important feedback, long =
enough
before 1.0 to be able to still tweak the design if necessary.

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Thursday, April 03, 2003 2:27 PM
To: j=FCrgen h=F6ller [werk3AT];
spr...@li...
Subject: Re: [Springframework-developer] Transaction support


Juergen,

I needed to put that check in to get the tests to pass. However, the
clarification about how PlatformTransactionManager implementations =
should
behave would also resolve the problem (meaning I could modify the test =
case,
not the class).

I haven't looked at your code in great detail, but from what I've seen =
it
looks good and I endorse the design.

Regards,
Rod


Hi Rod,

I've just seen your modifications to TransactionInterceptor. You've =
added
explicit programmatic rollback handling, i.e.

if (status !=3D null && !status.isRollbackOnly()) {
// Normal course of transaction: commit
doCommit();
}
else {
// Handle programmatic rollback
doRollback();
}

where doCommit and doRollback call PlatformTransactionManager's commit =
and
rollback, respectively. Technically, this isn't necessary, as the
PlatformTransactionManager implementation is supposed to handle this. =
That
way, every transaction manager client can benefit from it implicitly.
Unfortunately, PlatformTransactionManager's documentation currently =
doesn't
state that, so I will add appropriate JavaDoc.

By deriving from AbstractPlatformTransactionManager instead of =
implementing
PlatformTransactionManager directly, a transaction manager =
implementation
can benefit from the former's programmatic rollback and propagation =
behavior
handling. A subclass just needs to implement doCommit, doRollback, etc
without having to care about such case handling that will normally be =
the
same (see JtaTransactionManager).

All things considered, I suggest to remove the explicit check above if =
you
don't mind, as it is unnecessary.

Generally, what do you think of the current state of the transaction
support? Any limitations or inappropriate design decisions?






-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:=20
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Transaction support

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

Juergen, guys,
are you planning any sample apps/detailed usage docs (on transaction =
support
for example) for 0.8 release?

Rod,=20
when do you think the aopalliance.org will be up and running?

Thanks.

Dmitriy.

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
Sent: Thursday, April 03, 2003 07:39 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Transaction support


Rod,

I guess removing the check in TransactionInterceptor and modifying the =
test
case accordingly will solve the issue.

Now that we seem to approach a certain degree of stability in terms of
transaction support too, we should actively consider releasing 0.8. =
We're
not really following "release early, release often" up to now...

A combined developer download will be enough for the moment, I assume, =
we
don't really need a binary-only download before 1.0. Have you looked at =
how
SourceForge's release support works already? It shouldn't be hard to =
figure
out.

Even for 0.8, we should try to raise some attention just after the =
release,
for example at TheServerSide. We could gain important feedback, long =
enough
before 1.0 to be able to still tweak the design if necessary.

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Thursday, April 03, 2003 2:27 PM
To: j=FCrgen h=F6ller [werk3AT];
spr...@li...
Subject: Re: [Springframework-developer] Transaction support


Juergen,

I needed to put that check in to get the tests to pass. However, the
clarification about how PlatformTransactionManager implementations =
should
behave would also resolve the problem (meaning I could modify the test =
case,
not the class).

I haven't looked at your code in great detail, but from what I've seen =
it
looks good and I endorse the design.

Regards,
Rod


Hi Rod,

I've just seen your modifications to TransactionInterceptor. You've =
added
explicit programmatic rollback handling, i.e.

if (status !=3D null && !status.isRollbackOnly()) {
// Normal course of transaction: commit
doCommit();
}
else {
// Handle programmatic rollback
doRollback();
}

where doCommit and doRollback call PlatformTransactionManager's commit =
and
rollback, respectively. Technically, this isn't necessary, as the
PlatformTransactionManager implementation is supposed to handle this. =
That
way, every transaction manager client can benefit from it implicitly.
Unfortunately, PlatformTransactionManager's documentation currently =
doesn't
state that, so I will add appropriate JavaDoc.

By deriving from AbstractPlatformTransactionManager instead of =
implementing
PlatformTransactionManager directly, a transaction manager =
implementation
can benefit from the former's programmatic rollback and propagation =
behavior
handling. A subclass just needs to implement doCommit, doRollback, etc
without having to care about such case handling that will normally be =
the
same (see JtaTransactionManager).

All things considered, I suggest to remove the explicit check above if =
you
don't mind, as it is unnecessary.

Generally, what do you think of the current state of the transaction
support? Any limitations or inappropriate design decisions?






-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:=20
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] javadocs

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

Hi Isabelle,

I've also noticed repeatedly that some JavaDocs are quite erroneous. =
Thanks for volunteering! Rod, we should definitely give Isabelle commit =
access to be able to fix these issues.

Apropos JavaDoc, we haven't decided which comment style we want to =
endorse:
- the third person style, e.g. "Commits the transaction";
- or the command style, e.g. "Commit the transaction".

The former is rather from the caller's view, the latter from the =
implementer's view. I'm used to the former style, but currently many =
Spring classes have comments of the latter style, so I'm constantly in =
doubt how to handle this.

Juergen


-----Original Message-----
From: Isabelle Muszynski [mailto:met...@pa...]
Sent: Thursday, April 03, 2003 2:34 PM
To: spr...@li...
Subject: [Springframework-developer] javadocs


Hi everyone,

If I can get commit access to the cvs, I will fix all the javadocs. =
Currently gives about 83 warnings and 3 errors.

Isabelle

--=20
Isabelle Muszynski
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:=20
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Transaction support

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

Rod,

I guess removing the check in TransactionInterceptor and modifying the =
test case accordingly will solve the issue.

Now that we seem to approach a certain degree of stability in terms of =
transaction support too, we should actively consider releasing 0.8. =
We're not really following "release early, release often" up to now...

A combined developer download will be enough for the moment, I assume, =
we don't really need a binary-only download before 1.0. Have you looked =
at how SourceForge's release support works already? It shouldn't be hard =
to figure out.

Even for 0.8, we should try to raise some attention just after the =
release, for example at TheServerSide. We could gain important feedback, =
long enough before 1.0 to be able to still tweak the design if =
necessary.

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Thursday, April 03, 2003 2:27 PM
To: j=FCrgen h=F6ller [werk3AT];
spr...@li...
Subject: Re: [Springframework-developer] Transaction support


Juergen,

I needed to put that check in to get the tests to pass. However, the
clarification about how PlatformTransactionManager implementations =
should
behave would also resolve the problem (meaning I could modify the test =
case,
not the class).

I haven't looked at your code in great detail, but from what I've seen =
it
looks good and I endorse the design.

Regards,
Rod


Hi Rod,

I've just seen your modifications to TransactionInterceptor. You've =
added
explicit programmatic rollback handling, i.e.

if (status !=3D null && !status.isRollbackOnly()) {
// Normal course of transaction: commit
doCommit();
}
else {
// Handle programmatic rollback
doRollback();
}

where doCommit and doRollback call PlatformTransactionManager's commit =
and
rollback, respectively. Technically, this isn't necessary, as the
PlatformTransactionManager implementation is supposed to handle this. =
That
way, every transaction manager client can benefit from it implicitly.
Unfortunately, PlatformTransactionManager's documentation currently =
doesn't
state that, so I will add appropriate JavaDoc.

By deriving from AbstractPlatformTransactionManager instead of =
implementing
PlatformTransactionManager directly, a transaction manager =
implementation
can benefit from the former's programmatic rollback and propagation =
behavior
handling. A subclass just needs to implement doCommit, doRollback, etc
without having to care about such case handling that will normally be =
the
same (see JtaTransactionManager).

All things considered, I suggest to remove the explicit check above if =
you
don't mind, as it is unnecessary.

Generally, what do you think of the current state of the transaction
support? Any limitations or inappropriate design decisions?

[Springframework-developer] javadocs

[Isabelle M. <met...@pa...>]

Hi everyone,

If I can get commit access to the cvs, I will fix all the javadocs. Currently gives about 83 warnings and 3 errors.

Isabelle

-- 
Isabelle Muszynski
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89

Re: [Springframework-developer] Transaction support

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

Juergen,

I needed to put that check in to get the tests to pass. However, the
clarification about how PlatformTransactionManager implementations should
behave would also resolve the problem (meaning I could modify the test case,
not the class).

I haven't looked at your code in great detail, but from what I've seen it
looks good and I endorse the design.

Regards,
Rod


Hi Rod,

I've just seen your modifications to TransactionInterceptor. You've added
explicit programmatic rollback handling, i.e.

if (status != null && !status.isRollbackOnly()) {
// Normal course of transaction: commit
doCommit();
}
else {
// Handle programmatic rollback
doRollback();
}

where doCommit and doRollback call PlatformTransactionManager's commit and
rollback, respectively. Technically, this isn't necessary, as the
PlatformTransactionManager implementation is supposed to handle this. That
way, every transaction manager client can benefit from it implicitly.
Unfortunately, PlatformTransactionManager's documentation currently doesn't
state that, so I will add appropriate JavaDoc.

By deriving from AbstractPlatformTransactionManager instead of implementing
PlatformTransactionManager directly, a transaction manager implementation
can benefit from the former's programmatic rollback and propagation behavior
handling. A subclass just needs to implement doCommit, doRollback, etc
without having to care about such case handling that will normally be the
same (see JtaTransactionManager).

All things considered, I suggest to remove the explicit check above if you
don't mind, as it is unnecessary.

Generally, what do you think of the current state of the transaction
support? Any limitations or inappropriate design decisions?

RE: [Springframework-developer] Transaction support

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

Hi Rod,

I've just seen your modifications to TransactionInterceptor. You've =
added explicit programmatic rollback handling, i.e.

	if (status !=3D null && !status.isRollbackOnly()) {
		// Normal course of transaction: commit
		doCommit();
	}
	else {
		// Handle programmatic rollback
		doRollback();
	}

where doCommit and doRollback call PlatformTransactionManager's commit =
and rollback, respectively. Technically, this isn't necessary, as the =
PlatformTransactionManager implementation is supposed to handle this. =
That way, every transaction manager client can benefit from it =
implicitly. Unfortunately, PlatformTransactionManager's documentation =
currently doesn't state that, so I will add appropriate JavaDoc.

By deriving from AbstractPlatformTransactionManager instead of =
implementing PlatformTransactionManager directly, a transaction manager =
implementation can benefit from the former's programmatic rollback and =
propagation behavior handling. A subclass just needs to implement =
doCommit, doRollback, etc without having to care about such case =
handling that will normally be the same (see JtaTransactionManager).

All things considered, I suggest to remove the explicit check above if =
you don't mind, as it is unnecessary.=20

Generally, what do you think of the current state of the transaction =
support? Any limitations or inappropriate design decisions?

Juergen


-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT]=20
Sent: Friday, March 28, 2003 7:43 PM
To: spr...@li...
Subject: [Springframework-developer] Transaction support


Hi Rod, everybody,

I've checked in the following major changes:

- JndiServices is now a static helper (used in DataSourceUtils, =
JmsTemplate, and the EJB access classes); ContextFactory is dissolved =
for the time being.

- SingleConnectionDataSource can now wrap the underlying single =
connection to suppress close calls (via a DynamicProxy), to be able to =
accept close() calls from non-SmartDataSource aware users like O/R =
mapping toolkits.

- introduced generic TransactionStatus for programmatic rollback etc.

- moved PlatformTransactionManager from the AOP package to the =
transaction package, and reworked it (now features a getTransaction =
method taking propagationBehavior and isolationLevel parameters and =
returning a TransactionStatus, and commit and rollback methods).

- moved propagation behavior and isolation level constants to =
PlatformTransactionManager, using the java.sql.Connection values for the =
latter and adding a "default" value.

- added TransactionTemplate+TransactionCallback analogous to =
JdbcTemplate, the callback getting the TransactionStatus for otpional =
programmatic control and returning a result object to be able to return =
an object to the original caller.

- reworked AOP's TxControl into TransactionControl that uses =
TransactionStatus.

- completed transaction exceptions, modelling =
HeuristicCompletionException with an outcome state instead of a =
dedicated hierarchy for these rather rare situations.

- introduced JtaServices helper class and JtaTransactionManager =
implementation in com.interface21.transaction.jta (no dedicated =
JtaTemplate, easily achievable via feeding a JtaTransactionManager to =
TransactionTemplate).

- introduced SingleConnectionTransactionManager in =
com.interface21.transaction.mock, a transaction manager for =
SingleConnectionDataSource, handling autoCommit state and =
commit/rollback of the single underlying connection (for testing =
purposes, and for being able to run server-oriented data access and =
business logic transactionally in a standalone application).

- introduced AbstractPlatformTransactionManager in =
com.interface21.transaction.support, allowing for easy implementation of =
PlatformTransactionManagers (handling existing transactions, =
programmatic rollback-only, non-transactional fallback, etc), used by =
both JtaTransactionManager and SingleConnectionTransactionManager.

- introduced TransactionCallbackWithoutResult in =
com.interface21.transaction.support, allowing for implementing a =
doInTransaction version without the need to return a (null) result.

Rod, please check the AOP transaction interceptor, I've not tested it =
beyond the test suite. I am aware that we might still need some tweaking =
of the transaction support in terms of design, but I like the current =
version, and I consider it a good basis. I hope you like the design =
changes, of course I'm open to any suggestions.

Finally, I have that there aren't any tests for the transaction package =
yet - they are forthcoming, promised! (repeat to myself: "test first" =
"test first" "test first"...)

Regards,
Juergen


DI J=FCrgen H=F6ller
Senior System Architect
__________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

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



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Memory leak

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

Gang,

the memory leak problem I've posted before is resolved. Upgrading from
JBoss3.0.4/Jetty to JBoss3.0.6/Tomcat4.1 did the trick :-)

Cheers,

Dmitriy.

[Springframework-developer] Transaction support

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

Hi Rod, everybody,

I've checked in the following major changes:

- JndiServices is now a static helper (used in DataSourceUtils, =
JmsTemplate, and the EJB access classes); ContextFactory is dissolved =
for the time being.

- SingleConnectionDataSource can now wrap the underlying single =
connection to suppress close calls (via a DynamicProxy), to be able to =
accept close() calls from non-SmartDataSource aware users like O/R =
mapping toolkits.

- introduced generic TransactionStatus for programmatic rollback etc.

- moved PlatformTransactionManager from the AOP package to the =
transaction package, and reworked it (now features a getTransaction =
method taking propagationBehavior and isolationLevel parameters and =
returning a TransactionStatus, and commit and rollback methods).

- moved propagation behavior and isolation level constants to =
PlatformTransactionManager, using the java.sql.Connection values for the =
latter and adding a "default" value.

- added TransactionTemplate+TransactionCallback analogous to =
JdbcTemplate, the callback getting the TransactionStatus for otpional =
programmatic control and returning a result object to be able to return =
an object to the original caller.

- reworked AOP's TxControl into TransactionControl that uses =
TransactionStatus.

- completed transaction exceptions, modelling =
HeuristicCompletionException with an outcome state instead of a =
dedicated hierarchy for these rather rare situations.

- introduced JtaServices helper class and JtaTransactionManager =
implementation in com.interface21.transaction.jta (no dedicated =
JtaTemplate, easily achievable via feeding a JtaTransactionManager to =
TransactionTemplate).

- introduced SingleConnectionTransactionManager in =
com.interface21.transaction.mock, a transaction manager for =
SingleConnectionDataSource, handling autoCommit state and =
commit/rollback of the single underlying connection (for testing =
purposes, and for being able to run server-oriented data access and =
business logic transactionally in a standalone application).

- introduced AbstractPlatformTransactionManager in =
com.interface21.transaction.support, allowing for easy implementation of =
PlatformTransactionManagers (handling existing transactions, =
programmatic rollback-only, non-transactional fallback, etc), used by =
both JtaTransactionManager and SingleConnectionTransactionManager.

- introduced TransactionCallbackWithoutResult in =
com.interface21.transaction.support, allowing for implementing a =
doInTransaction version without the need to return a (null) result.

Rod, please check the AOP transaction interceptor, I've not tested it =
beyond the test suite. I am aware that we might still need some tweaking =
of the transaction support in terms of design, but I like the current =
version, and I consider it a good basis. I hope you like the design =
changes, of course I'm open to any suggestions.

Finally, I have that there aren't any tests for the transaction package =
yet - they are forthcoming, promised! (repeat to myself: "test first" =
"test first" "test first"...)

Regards,
Juergen


DI J=FCrgen H=F6ller
Senior System Architect
__________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

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

RE: [Springframework-developer] Help!!!

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

Well obviously :-)
I thought it was suppose to be cleaned up automatically by the framework.
How else would it be possible if we pass the model Map reference to a
Controller (encapsulating it in the ModelAndView instance) and then it gets
passed to a View.render() method. I feel that the life time of the model Map
should end in the View.render() Anybody correct me if I am wrong.

Thanks,

Dmitriy.

-----Original Message-----
From: William G. Thompson, Jr. [mailto:wg...@rc...]
Sent: Thursday, March 27, 2003 16:03 PM
To: Kopylenko, Dmitry
Subject: Re: [Springframework-developer] Help!!!


You have a memory leak!  :)  lol

Who cleans up the the model?



Kopylenko, Dmitry wrote:
> Hello everybody. I have a big problem and if anybody could help I would
> definitely appreciate it.
> 
> In the nutshel, I have a MultiActionController with one of the request
> handling methods which does retrieve three lists of "reference data" from
> ApplicationContext (I load the reference data at the bootstrap, similarly
to
> CachingCalendar in the BoxOffice application) and puts the "lists" in the
> model Map to make it available to a View:
> 
> public ModelAndView processProgramInquiryAdd(HttpServletRequest request,
> HttpServletResponse response)
> 	throws ServletException {
> 
> 		Map model = new HashMap();
> 		model.put("programLookup", ((GradApplicationReferenceData)
> getApplicationContext().getBean		
> 	
> ("gradApplicationReferenceData")).getPrograms());
> 		model.put("stateLookup", ((GradApplicationReferenceData)
> getApplicationContext().getBean
> 	
> ("gradApplicationReferenceData")).getStates());
> 		model.put("countryLookup", ((GradApplicationReferenceData)
> getApplicationContext().getBean
> 	
> ("gradApplicationReferenceData")).getCountries());
> 
> 		// Rest of the processing
> 		.........................
> 		return new ModelAndView(ESTABLISH_NEW_PROGRAM_INQUIRY_VIEW,
> model);
> }
> 
> My dev. environment is NT4 with around 300M of RAM, Sun's JDK 1.4 and
JBoss
> 3.0.4
> When I run this request handling method several times (e.g. hit the submit
> button on the web page), after about the third time the JVM dies with:
> 
> Exception in thread "CompileThread0" java.lang.OutOfMemoryError: requested
> 32756 bytes
> 
> When I comment out the block of code which puts the "reference lists" into
a
> model Map, it runs fine.
> Could anybody, please tell me if the code is ok and it does not create a
> problem. And what could it be?
> 
> Thanks,
> 
> Dmitriy.

[Springframework-developer] Help!!!

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

Hello everybody. I have a big problem and if anybody could help I would
definitely appreciate it.

In the nutshel, I have a MultiActionController with one of the request
handling methods which does retrieve three lists of "reference data" from
ApplicationContext (I load the reference data at the bootstrap, similarly to
CachingCalendar in the BoxOffice application) and puts the "lists" in the
model Map to make it available to a View:

public ModelAndView processProgramInquiryAdd(HttpServletRequest request,
HttpServletResponse response)
	throws ServletException {

		Map model = new HashMap();
		model.put("programLookup", ((GradApplicationReferenceData)
getApplicationContext().getBean		
	
("gradApplicationReferenceData")).getPrograms());
		model.put("stateLookup", ((GradApplicationReferenceData)
getApplicationContext().getBean
	
("gradApplicationReferenceData")).getStates());
		model.put("countryLookup", ((GradApplicationReferenceData)
getApplicationContext().getBean
	
("gradApplicationReferenceData")).getCountries());

		// Rest of the processing
		.........................
		return new ModelAndView(ESTABLISH_NEW_PROGRAM_INQUIRY_VIEW,
model);
}

My dev. environment is NT4 with around 300M of RAM, Sun's JDK 1.4 and JBoss
3.0.4
When I run this request handling method several times (e.g. hit the submit
button on the web page), after about the third time the JVM dies with:

Exception in thread "CompileThread0" java.lang.OutOfMemoryError: requested
32756 bytes

When I comment out the block of code which puts the "reference lists" into a
model Map, it runs fine.
Could anybody, please tell me if the code is ok and it does not create a
problem. And what could it be?

Thanks,

Dmitriy.

RE: [Springframework-developer] Release?

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

I agree.  I prefer a combined download for developers, including
sources, third party libs, and Spring binaries.  Include a readme file
though indicating version #'s for the third-party files.

I'm indifferent in regards to the examples.




-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Monday, March 24, 2003 2:04 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Release?

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Update

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

<jh>
OK, let's move PlatformTransactionManager to com.interface21.transaction and
try to stick with it. One concern that I see for JtaTemplate is that it uses
JTA status information in its execute method, for flexible transaction
propagation (commit and rollback handling). With PlatformTransactionManager,
we could solve this with some additional status method (maybe just a flag).
Of course, TransactionInterceptor should work the same way. I'll try to
rework JtaTemplate into a TransactionTemplate accordingly, some time this
week.
</jh>

OK. We'll probably also need to think about where the TxControl class
belongs. If we have an integrated infrastructure maybe we could move it also
to com.interface21.transaction and have the ability to do programmatic
rollback without an exception using TransactionTemplate or with a
TransactionInterceptor.

Perhaps the status inner class in TxControl would do what you require and we
could pass that to the PlatformTransactionManager interface?

I think we're onto something here. A really nice, *usable* integrated
transaction management approach is very valuable.

Regards,
Rod

RE: [Springframework-developer] Update

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

One more note concerning =
PlatformTransactionManager/TransactionInterceptor/TxControl: We will =
need to change the interceptor's custom rollback-only functionality to =
setRollbackOnly support in PlatformTransactionManager, to allow for =
taking part in existing transactions with proper rollback-only =
notification.

A JtaTransactionManager implementation will then be an unrestricted and =
very thin wrapper around the JtaServices helper class.

BTW, I don't worry about efficiency concerning our transaction support. =
I'd just like to keep both the API and the implementation as simple as =
possible, of course while still providing as much power and flexibility =
as necessary.

Juergen


-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT]=20
Sent: Tuesday, March 25, 2003 6:16 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Update


Hi Rod,

<rj>
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.
</rj>

Ehm, I've indeed tried to solely create a static JtaServices helper =
class at first. After your comments, I've reworked it into a JtaTemplate =
object that uses JtaServices helper methods.

<rj>
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.
</rj>

The question is: Is JndiServices a trivial thing (static helper class), =
or should it be turned into JndiTemplate (true object)? Note that =
DataSourceUtils uses JndiServices... Should a static helper class need =
to create a true object, within Spring? And if we turn JndiServices into =
a true object, we would need to apply the same to JtaServices (that just =
contains simple access methods used by JtaTemplate), for the sake of =
consistency.

So let's decide: static helper classes or true objects?
- JndiServices (eventually renamed to JndiTemplate);
- DataSourceUtils (using JndiServices);
- JtaServices (using JndiServices).
Note that JtaTemplate will be a true object anyway.

<rj>
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.
</rj>

Agreed, we need to regard testability. Regarding JNDI, this is easy, see =
MockInitialContextFactoryBuilder. It isn't necessary to make =
JndiServices a true object to achieve this.

I guess this is also an issue of convenience: Static helper classes are =
very handy to use. JNDI lookups aren't hard with plain JNDI (OK, =
InitialContexts should be closed in a finally block, but this isn't =
absolutely necessary, in contrast to JDBC), so IMHO a utility class must =
provide noticeable simplification beyond it.

Regarding JTA, the tradeoff is different. I agree that there are very =
valid reasons for making JtaTemplate a true object. I consider the =
lower-level access/exception conversion stuff in JtaServices rather a =
candidate for a static helper class, nevertheless.

<rj>
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.
(...)
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.
(...)
OK. If we stick with PlatformTransactionManager it should probably move =
to
com.interface21.transaction, along with the exceptions.
</rj>

OK, let's move PlatformTransactionManager to com.interface21.transaction =
and try to stick with it. One concern that I see for JtaTemplate is that =
it uses JTA status information in its execute method, for flexible =
transaction propagation (commit and rollback handling). With =
PlatformTransactionManager, we could solve this with some additional =
status method (maybe just a flag). Of course, TransactionInterceptor =
should work the same way. I'll try to rework JtaTemplate into a =
TransactionTemplate accordingly, some time this week.

Regards,
Juergen


-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Update

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

Hi Rod,

<rj>
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.
</rj>

Ehm, I've indeed tried to solely create a static JtaServices helper =
class at first. After your comments, I've reworked it into a JtaTemplate =
object that uses JtaServices helper methods.

<rj>
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.
</rj>

The question is: Is JndiServices a trivial thing (static helper class), =
or should it be turned into JndiTemplate (true object)? Note that =
DataSourceUtils uses JndiServices... Should a static helper class need =
to create a true object, within Spring? And if we turn JndiServices into =
a true object, we would need to apply the same to JtaServices (that just =
contains simple access methods used by JtaTemplate), for the sake of =
consistency.

So let's decide: static helper classes or true objects?
- JndiServices (eventually renamed to JndiTemplate);
- DataSourceUtils (using JndiServices);
- JtaServices (using JndiServices).
Note that JtaTemplate will be a true object anyway.

<rj>
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.
</rj>

Agreed, we need to regard testability. Regarding JNDI, this is easy, see =
MockInitialContextFactoryBuilder. It isn't necessary to make =
JndiServices a true object to achieve this.

I guess this is also an issue of convenience: Static helper classes are =
very handy to use. JNDI lookups aren't hard with plain JNDI (OK, =
InitialContexts should be closed in a finally block, but this isn't =
absolutely necessary, in contrast to JDBC), so IMHO a utility class must =
provide noticeable simplification beyond it.

Regarding JTA, the tradeoff is different. I agree that there are very =
valid reasons for making JtaTemplate a true object. I consider the =
lower-level access/exception conversion stuff in JtaServices rather a =
candidate for a static helper class, nevertheless.

<rj>
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.
(...)
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.
(...)
OK. If we stick with PlatformTransactionManager it should probably move =
to
com.interface21.transaction, along with the exceptions.
</rj>

OK, let's move PlatformTransactionManager to com.interface21.transaction =
and try to stick with it. One concern that I see for JtaTemplate is that =
it uses JTA status information in its execute method, for flexible =
transaction propagation (commit and rollback handling). With =
PlatformTransactionManager, we could solve this with some additional =
status method (maybe just a flag). Of course, TransactionInterceptor =
should work the same way. I'll try to rework JtaTemplate into a =
TransactionTemplate accordingly, some time this week.

Regards,
Juergen