springframework-developer — Spring Framework developers list

RE: [Springframework-developer] Velocity / FreeMarker request and session attributes

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

> <PedanticQuoteFromRod'sTssPostAndFinalWordOnTheMatter>
> Spring 1.1 final is scheduled for release in mid August, and will be =
100%
> backward compatible with Spring 1.0.2.
> </PedanticQuoteFromRod'sTssPostAndFinalWordOnTheMatter>

Damn ;-)

Seriously, we can allow overriding by default, of course. Question is: =
Aren't there also valid uses cases for letting model attributes override =
session attributes, i.e. the other way round?

So there's actually 2 scenarios, with 2 options each:

1.
a) let session attributes override model attributes
b) throw an exception if session attributes would override model =
attributes

2.
a) let model attributes override session attributes
b) throw an exception if model attributes would override session =
attributes

And then there's the same for request attributes... I guess it's better =
to keep stuff simple here, i.e. assume typical use cases rather than =
allow for all those configuration options.

Juergen

Re: [Springframework-developer] Velocity / FreeMarker request and session attributes

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

> Well spotted, Darren - I added those checks because I considered it an
> error to silently override existing attributes. Unfortunately, you had =
a
> use case for just that... We can certainly make this configurable, if y=
ou
> think that your use case is actually recommendable ;-)

don't know whether it's recommendable or not, but it won't hurt to have i=
t
in if the default is to throw the exception I think.  I'll modify local
sources here and test (I'm at work and can't get to the CVS servers) and
commit it tonight if there's no objections.

> BTW, strictly speaking, we're still 100% compatible to Spring 1.0, beca=
use
> the "exposeSessionAttribute" feature has been introduced in Spring 1.0.=
2
> ;-)

oooh - slippery, but I'm not letting you get away with it that easily..

<PedanticQuoteFromRod'sTssPostAndFinalWordOnTheMatter>
Spring 1.1 final is scheduled for release in mid August, and will be 100%
backward compatible with Spring 1.0.2.
</PedanticQuoteFromRod'sTssPostAndFinalWordOnTheMatter>

hehe ;-)

Cheers!

--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm

Re: [Springframework-developer] @since and @version tags

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

> So far it's 3 in favor, 2 against

+1 for @since with version numbers (or dates if it was pre 1.0)

Quite like $Id tags, but not if they're going to cause operational
problems (ie with branching).  Don't know if that counts as + or - 1  :)

D.
--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm

Re: [Springframework-developer] Velocity / FreeMarker request and session attributes

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

Well spotted, Darren - I added those checks because I considered it an =
error to silently override existing attributes. Unfortunately, you had a =
use case for just that... We can certainly make this configurable, if =
you think that your use case is actually recommendable ;-)

BTW, strictly speaking, we're still 100% compatible to Spring 1.0, =
because the "exposeSessionAttribute" feature has been introduced in =
Spring 1.0.2 ;-)

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Darren Davison
Sent: Thursday, July 29, 2004 12:51 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Velocity / FreeMarker request
and session attributes



> I think it's good to make the behaviour explicit and I'll change my
> controller code to manage the change, but just to be aware - it's not =
100%
> backward compatible with 1.0.2 as advertised :-)

actually, is there any value in adding (yet) another bean property to
AbstractTemplateView that defines the behaviour here?

myVelocityView.allowSessionOverride=3Dtrue

to force the old behaviour, with the default being false which causes =
the
ServletException to be thrown?  Otherwise, I have to start kludging =
model
attribute names somehow I think..

Regards,

--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] TransformTag has no setter for htmlEscape attribute in 1.1RC1

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

Tom,

Oops, this has been introduced through my recent refactoring of the =
tags, for behavior that is consistent with our new Velocity/FreeMarker =
macros. Thanks for spotting this!

As TransformTag didn't actually do HTML escaping, I've derived it from =
RequestContextAwareTag rather than HtmlEscapingAwareTag. Neither Tomcat =
nor Resin complained, so I didn't notice that the TLD actually states an =
"htmlEscape" property.

I've just made TransformTag actually HTML-escape its result value (if =
demanded), deriving it from HtmlEscapingAwareTag now. I'll commit this =
promptly.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Tom Turelinckx
Sent: Thursday, July 29, 2004 2:46 PM
To: spr...@li...
Subject: [Springframework-developer] TransformTag has no setter for
htmlEscape attribute in 1.1RC1


After upgrading to 1.1RC1 (we were previously using a cvs version of a
couple of days ago), we get an error when accessing any jsp that uses
the spring taglib:

weblogic.servlet.jsp.JspException: (line 6): Error in using tag library
uri=3D'http://www.springframework.org/tags' prefix=3D'spring': The Tag =
class
'org.springframework.web.servlet.tags.TransformTag' has no setter method
corresponding to TLD declared attribute 'htmlEscape', (JSP 1.1 spec,
5.4.1)

This is on WebLogic 8.1sp2.

And indeed, the TLD declares a htmlEscape attribute while there is no
corresponding setter in TransformTag.
Maybe TransformTag should extend HtmlEscapingAwareTag (and actually use
html escaping) instead of RequestContextAwareTag?

Regards,
Tom.


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] TransformTag has no setter for htmlEscape attribute in 1.1RC1

[Tom T. <tom...@pr...>]

After upgrading to 1.1RC1 (we were previously using a cvs version of a
couple of days ago), we get an error when accessing any jsp that uses
the spring taglib:

weblogic.servlet.jsp.JspException: (line 6): Error in using tag library
uri='http://www.springframework.org/tags' prefix='spring': The Tag class
'org.springframework.web.servlet.tags.TransformTag' has no setter method
corresponding to TLD declared attribute 'htmlEscape', (JSP 1.1 spec,
5.4.1)

This is on WebLogic 8.1sp2.

And indeed, the TLD declares a htmlEscape attribute while there is no
corresponding setter in TransformTag.
Maybe TransformTag should extend HtmlEscapingAwareTag (and actually use
html escaping) instead of RequestContextAwareTag?

Regards,
Tom.

Re: [Springframework-developer] @since and @version tags

[Dmitriy K. <dko...@ru...>]

So far it's 3 in favor, 2 against


Rob Harrop wrote:

>+1 here as well - I find that the $Id$ tag is quite useful.
> 
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Rod Johnson
>Sent: 29 July 2004 13:09
>To: spr...@li...
>Subject: Re: [Springframework-developer] @since and @version tags
>
>+1 for $Id.
>
>I like to be able to see who last edited the file without looking at
>resource history (for example, offline). It also helps to see whether a CVS
>commit has succeeded.
>
>----- Original Message -----
>From: "Dmitriy Kopylenko" <dko...@ru...>
>To: <spr...@li...>
>Sent: Thursday, July 29, 2004 12:49 PM
>Subject: Re: [Springframework-developer] @since and @version tags
>
>
>  
>
>>Well, let's take a vote. I'm for $Id tags (+1)
>>    
>>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

RE: [Springframework-developer] @since and @version tags

[Rob H. <ro...@ca...>]

+1 here as well - I find that the $Id$ tag is quite useful.
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Rod Johnson
Sent: 29 July 2004 13:09
To: spr...@li...
Subject: Re: [Springframework-developer] @since and @version tags

+1 for $Id.

I like to be able to see who last edited the file without looking at
resource history (for example, offline). It also helps to see whether a CVS
commit has succeeded.

----- Original Message -----
From: "Dmitriy Kopylenko" <dko...@ru...>
To: <spr...@li...>
Sent: Thursday, July 29, 2004 12:49 PM
Subject: Re: [Springframework-developer] @since and @version tags


> Well, let's take a vote. I'm for $Id tags (+1)




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] @since and @version tags

[Thomas R. <tho...@tr...>]

-1

I see no value in having the @version/$Id tags in the source - CVS can 
give you this if and when you need it.  The @since with a release 
version would be nice for the JavaDocs and would be consistent with Java 
itself.

Thomas
 
Dmitriy Kopylenko wrote:

> Well, let's take a vote. I'm for $Id tags (+1)
>
> Regards,
> Dmitriy.
>
>
> jürgen höller [werk3AT] wrote:
>
>> I'd actually prefer if we drop $Id tags from all files. I personally 
>> don't think that they add much value. Of course, if a democratic 
>> decision goes in favor of those tags, well, I'll concede ;-)
>>
>> Regarding @since tags, we're currently using them with the creation 
>> date. That has been quite nice during our agile way towards 1.0. We 
>> could indeed reconsider to use version numbers there now.
>>
>> Any suggestions on how to apply a consistent style for all source 
>> files in a batch, without messing them up? $Id is probably easy, 
>> @since nearly impossible, parameter alignment easy again.
>>
>> Juergen
>>
>>
>> ________________________________
>>
>> Von: spr...@li... im Auftrag 
>> von Colin Sampaleanu
>> Gesendet: Mi 28.07.2004 20:38
>> An: spr...@li...
>> Betreff: Re: [Springframework-developer] @since and @version tags
>>
>>
>>
>> Dmitriy Kopylenko wrote:
>>
>>  
>>
>>>> I like id keywords...they're mainly in the code through my classes or
>>>> classes I've edited... (Damn, if it's standardized, I won't know if 
>>>> I've
>>>> worked on a particular file any more :-)
>>>>
>>>>
>>>>     
>>>
>>> I also insert $Id:$ when I work on existing classes or create new ones
>>> ;-)
>>>
>>> Dmitriy.
>>>   
>>
>>
>> I personally like $Id tags. But they do suck big time when trying to
>> merge files back in after a branch, causing a conflict/change to exist
>> when there shouldn't be any... There seems to be a trend to going away
>> from using them in files, by some people, for this reason.
>>
>> Colin
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by BEA Weblogic Workshop
>> FREE Java Enterprise J2EE developer tools!
>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by BEA Weblogic Workshop
>> FREE Java Enterprise J2EE developer tools!
>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>> http://ads.osdn.com/?ad_idG21&alloc_id040&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>  
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>

Re: [Springframework-developer] @since and @version tags

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

Jérôme BERNARD wrote:

> Colin Sampaleanu wrote:
>
>> Jérôme BERNARD wrote:
>>
>>> Colin Sampaleanu wrote:
>>>
>>>> Dmitriy Kopylenko wrote:
>>>>
>>>>>
>>>>>> I like id keywords...they're mainly in the code through my 
>>>>>> classes or
>>>>>> classes I've edited... (Damn, if it's standardized, I won't know 
>>>>>> if I've
>>>>>> worked on a particular file any more :-)
>>>>>>  
>>>>>>
>>>>> I also insert $Id:$ when I work on existing classes or create new 
>>>>> ones ;-)
>>>>>
>>>>> Dmitriy.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I personally like $Id tags. But they do suck big time when trying 
>>>> to merge files back in after a branch, causing a conflict/change to 
>>>> exist when there shouldn't be any... There seems to be a trend to 
>>>> going away from using them in files, by some people, for this reason.
>>>
>>>
>>>
>>>
>>> Simply use the "-kk" option.
>>> Have a look at: http://www.loria.fr/~molli/cvs/doc/cvs_toc.html#TOC96
>>> Keywords are not an issue at all for branches & merges.
>>>
>> I think I'm missing something. If you just use -kk, then you don't 
>> get any actual values substituted, only the keyword itself gets left 
>> in there. Are you suggesting that for doing the merge, you check out 
>> both branches with -kk, and then merge using those copies? Sort of a 
>> pain, although it would work.
>>
>> Colin
>
>
> I should have sent this link instead 
> http://www.rons.net.cn/htp/cvs/cvs_5.html#SEC64 :-)
> Basically, with the "-kk" option, it simply ignores the "expanded 
> values". No need to checkout with "-kk".

Ok, I see what you are getting at. The issue is that this overrides the 
binary mode on files that are binary. Not very realistic in a large 
codebase.

Colin

Re: [Springframework-developer] @since and @version tags

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

+1 for $Id.

I like to be able to see who last edited the file without looking at
resource history (for example, offline). It also helps to see whether a CVS
commit has succeeded.

----- Original Message -----
From: "Dmitriy Kopylenko" <dko...@ru...>
To: <spr...@li...>
Sent: Thursday, July 29, 2004 12:49 PM
Subject: Re: [Springframework-developer] @since and @version tags


> Well, let's take a vote. I'm for $Id tags (+1)

Re: [Springframework-developer] @since and @version tags

[Dmitriy K. <dko...@ru...>]

Well, let's take a vote. I'm for $Id tags (+1)

Regards,
Dmitriy.


jürgen höller [werk3AT] wrote:

>I'd actually prefer if we drop $Id tags from all files. I personally don't think that they add much value. Of course, if a democratic decision goes in favor of those tags, well, I'll concede ;-)
> 
>Regarding @since tags, we're currently using them with the creation date. That has been quite nice during our agile way towards 1.0. We could indeed reconsider to use version numbers there now.
> 
>Any suggestions on how to apply a consistent style for all source files in a batch, without messing them up? $Id is probably easy, @since nearly impossible, parameter alignment easy again.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: Mi 28.07.2004 20:38
>An: spr...@li...
>Betreff: Re: [Springframework-developer] @since and @version tags
>
>
>
>Dmitriy Kopylenko wrote:
>
>  
>
>>>I like id keywords...they're mainly in the code through my classes or
>>>classes I've edited... (Damn, if it's standardized, I won't know if I've
>>>worked on a particular file any more :-)
>>>
>>>
>>>      
>>>
>>I also insert $Id:$ when I work on existing classes or create new ones
>>;-)
>>
>>Dmitriy.
>>    
>>
>
>I personally like $Id tags. But they do suck big time when trying to
>merge files back in after a branch, causing a conflict/change to exist
>when there shouldn't be any... There seems to be a trend to going away
>from using them in files, by some people, for this reason.
>
>Colin
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_idG21&alloc_id040&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

Re: [Springframework-developer] Velocity / FreeMarker request and session attributes

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

> I think it's good to make the behaviour explicit and I'll change my
> controller code to manage the change, but just to be aware - it's not 1=
00%
> backward compatible with 1.0.2 as advertised :-)

actually, is there any value in adding (yet) another bean property to
AbstractTemplateView that defines the behaviour here?

myVelocityView.allowSessionOverride=3Dtrue

to force the old behaviour, with the default being false which causes the
ServletException to be thrown?  Otherwise, I have to start kludging model
attribute names somehow I think..

Regards,

--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm

[Springframework-developer] Velocity / FreeMarker request and session attributes

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

1.1RC1 looks to have implemented a change to the behaviour in 1.0.2 for
exposing session or request attributes.  Previously, they would silently
be added to the model hiding model attributes of the same name.  Now it
throws a ServletException if a model attribute of the same name exists.

This affects one of my projects which assumes session scoped objects are
superior to controller generated values, so I now get an error page on
requests that tickle this functionality.

I think it's good to make the behaviour explicit and I'll change my
controller code to manage the change, but just to be aware - it's not 100=
%
backward compatible with 1.0.2 as advertised :-)

Cheers!

--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm

Re: [Springframework-developer] new 'RedirectViewResolver'

[Seth L. <set...@gm...>]

> No, the whole point is that the controller right now doesn't know what
> actual text of the view name is (it gets it from the success property
> for example, but it knows if it should return it as
>    new ModelAndView(getSuccessView(),...
> which is for a normal view (TilesJSTLView), or as
>   new ModelAndView(new RedirectView(getSuccessView(), true))

Right, we definitely don't want the controller knowing the view names.
 I meant to merely suggest that the controller has two properties, one
successView and another of business meaning (call it leaveView).  My
previous example would change to:

if (XXX) {
  return new ModelAndView(getSuccessView());
} else if (XXX and YYY) {
  return new ModelAndView(getLeaveView());
}

But I see exactly what you are saying...

Seth

Re: [Springframework-developer] @since and @version tags

[<jer...@xt...>]

Colin Sampaleanu wrote:

> Jérôme BERNARD wrote:
>
>> Colin Sampaleanu wrote:
>>
>>> Dmitriy Kopylenko wrote:
>>>
>>>>
>>>>> I like id keywords...they're mainly in the code through my classes or
>>>>> classes I've edited... (Damn, if it's standardized, I won't know 
>>>>> if I've
>>>>> worked on a particular file any more :-)
>>>>>  
>>>>>
>>>> I also insert $Id:$ when I work on existing classes or create new 
>>>> ones ;-)
>>>>
>>>> Dmitriy.
>>>
>>>
>>>
>>>
>>> I personally like $Id tags. But they do suck big time when trying to 
>>> merge files back in after a branch, causing a conflict/change to 
>>> exist when there shouldn't be any... There seems to be a trend to 
>>> going away from using them in files, by some people, for this reason.
>>
>>
>>
>> Simply use the "-kk" option.
>> Have a look at: http://www.loria.fr/~molli/cvs/doc/cvs_toc.html#TOC96
>> Keywords are not an issue at all for branches & merges.
>>
> I think I'm missing something. If you just use -kk, then you don't get 
> any actual values substituted, only the keyword itself gets left in 
> there. Are you suggesting that for doing the merge, you check out both 
> branches with -kk, and then merge using those copies? Sort of a pain, 
> although it would work.
>
> Colin

I should have sent this link instead 
http://www.rons.net.cn/htp/cvs/cvs_5.html#SEC64 :-)
Basically, with the "-kk" option, it simply ignores the "expanded 
values". No need to checkout with "-kk".

Jérôme.

Re: [Springframework-developer] @since and @version tags

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

I'd actually prefer if we drop $Id tags from all files. I personally =
don't think that they add much value. Of course, if a democratic =
decision goes in favor of those tags, well, I'll concede ;-)
=20
Regarding @since tags, we're currently using them with the creation =
date. That has been quite nice during our agile way towards 1.0. We =
could indeed reconsider to use version numbers there now.
=20
Any suggestions on how to apply a consistent style for all source files =
in a batch, without messing them up? $Id is probably easy, @since nearly =
impossible, parameter alignment easy again.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Mi 28.07.2004 20:38
An: spr...@li...
Betreff: Re: [Springframework-developer] @since and @version tags



Dmitriy Kopylenko wrote:

>
>> I like id keywords...they're mainly in the code through my classes or
>> classes I've edited... (Damn, if it's standardized, I won't know if =
I've
>> worked on a particular file any more :-)
>>=20
>>
> I also insert $Id:$ when I work on existing classes or create new ones
> ;-)
>
> Dmitriy.

I personally like $Id tags. But they do suck big time when trying to
merge files back in after a branch, causing a conflict/change to exist
when there shouldn't be any... There seems to be a trend to going away
from using them in files, by some people, for this reason.

Colin




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Question about Datasources and Transactions

[Thomas R. <tho...@tr...>]

Ollie,

I'll take a shot at answering your questions.

1.  I have not seen the behavior for this scenarion explicitly specified 
in any spec - JTS/JTA/EJB/JDBC.  My take is that it is implementation 
specific and it could depend on whether you used an XA enable driver or 
not.   If the driver is not XA enabled, then option _a_ would be the 
only possible one.  This is how I understand WebLogic to work in this 
case.  Don't know about JOTM.

2.  It depends on your configuration:

2.1  Spring's transaction management uses option _a_ for a "single 
resource" transaction definition using DataSourceTransactionManager or 
HibernateTransactionManager.  For this to work, you don't need a JTA 
implementation or an XA datasource - a Commons DBCP connection pool will 
work fine.  The "single datasource" transaction managers are of course 
only an option if your data access is limited to a single database. 

2.2  In the case of a JTA configuration, Spring would delegate the 
transaction management to the JTA implementation. Now, you are again 
dependent on the JTA implementation and how it would handle XA vs non-XA 
drivers.  For this you type of configuration you would use Spring's 
JTATransactionManager.  I've never used Hibernate in an XA environment, 
but I'm pretty sure you have to configure it to work with your JTA 
implementation.

Bottom line is that you should not code this logic into your application 
- you should rely on the transaction management implementation to manage 
the connenction(s) and the transaction context for you.  The trick is to 
pick a configuration that will work for your requirements as well as 
with your JDBC driver/database.

Hope this helps.

Thomas



Oliver Geisser wrote:

> Hi,
>
> we are currently evaluating an architecture for our application which 
> will use the follwing frameworks:
>
> Tomcat + Servlet + Spring + Hibernate + JOTM + XAPool + Quartz
> No EJB container!
>
> We are making fast progress (thanks for the very good docmentation of 
> Spring) but we want to understand all the details.
>
> We believe that we understand most of the details regarding Spring, 
> Hibernate sessions, Spring managing transaction, etc, but there are 
> still areas we have questions.
>
> To explain my question I will ask a EJB related question first to make 
> my Spring question more clear.
>
> Let's say I have an EJB SessionBean with declarative transaction 
> demarcation which will do JDBC calls like the following:
>
> -------------
> // some SessionBean
> ...
> Datasource ds = context.lookup(DATASOURCE_1_NAME);
> Connection con1 = ds.getConnection();
> Connection con2 = ds.getConnection();
>
> ... // execute some SQL on con1
> ... // execute some SQL on con2
>
> con1.close();
> con2.close();
>
> Connection con3 = ds.getConnection();
> ... // execute some SQL on con3
> con3.close();
> ----------------
>
> It is clear that it is the job of the EJB container to execute all SQL 
> in the same transaction. This can be achieved by:
>
> a) Connection con1, con2 and con3 all wrap the same physical connection
>    to the DB and this connection is commited at the end of the
>    transaction.
>
> b) Connection con1, con2 and con3 are three different physical
>    connections and the container will use a JTA Transaction Manager with
>    2PC to commit all connections at the end of the transaction.
>
> Our questions:
>
> 1) What is the specified behaviour for an EJB Container: a or b?
>
> Where is this specified: EJB Spec?, JDBC Spec?, which chapter?
> If this is implementation dependent, how does JBoss, WebSphere, BEA, 
> etc. solve it?
>
> 2) What is the corresponding Spring mechanism?
> We are not sure who is responsible for such a behaviour in our 
> architecture (see above) Is it Spring, Hibernate, XAPool, JOTM or do 
> we need to write our own infrastructure?
>
>
> Thanks, Olli
>
> --og
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>

Re: [Springframework-developer] new 'RedirectViewResolver'

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

Seth Ladd wrote:

>>The whole point is that the view name still doesn't have any meaning to
>>the controller. It's a logical identifier as far as the controller is
>>concerned (the controller only deals in terms of names it gets as
>>properties), but this is one mechanism for the resolving machinery to
>>tell one target view from another.
>>    
>>
>
>Yes, good point.
>
>If I read you correctly, it sounds like the controller is making the
>decision to redirect or not.  You could set two view names into the
>controller, and give them meaningful names.  The business logic in the
>controller will chooses which view name to forward on to.  But the
>words "redirect" are now left out.  The two view names you give to the
>Controller are mapped normally.
>
>Something like:
>
>if (xxx) {
>  return new ModelAndView("viewA");
>} else if (XXX and YYY) {
>  return new ModelAndView("viewB");
>}
>
>where:
>
>viewA is JstlView
>viewB is RedirectView
>
>Not sure if that's cleaner, though.  It does remove any references to
>redirecting inside the controller (both RedirectView and redirect: are
>gone).
>
>  
>
No, the whole point is that the controller right now doesn't know what 
actual text of the view name is (it gets it from the success property 
for example, but it knows if it should return it as
   new ModelAndView(getSuccessView(),...
which is for a normal view (TilesJSTLView), or as
  new ModelAndView(new RedirectView(getSuccessView(), true))
for a redirect, which defeats the whole purpose of it not knowing the 
actual names (it's actually a bit worse than that, as in some cases it 
does have hard-coded view names which it returns as a redirectview, but 
let's suppose those could be brought in as properties instead, same as 
successview or formview). Now the actual text of the view names do 
contain enough info for the resolving machinery to know whether it's 
meant for Tiles (a simple name like "login") or as some sort of url (a 
name like "xxxxx.html"). Whatever, the actual names in this case don't 
matter, just that they are of different format, but the point is that 
while view chaining is supposed to be for these kinds of scenarios, for 
these kinds of scenarios the existing code doesn't work. None of the 
view resolvers can be used to make these kinds of decisions.

Colin

Re: [Springframework-developer] Validation: multiple image buttons on forms

[Seth L. <set...@gm...>]

On Wed, 28 Jul 2004 20:39:35 -0400, Stefan D Sookraj
<ste...@us...> wrote:
> 
> 
> Seth,
> Thanks for the reply, but since this is need as part of my validator, is
> there not a way to get a hold of the request in the validator?

You can use the method onBindAndValidate().  That's in the Controller,
but at least you get access to the Request object in there.

> 
> BTW - I have a property on the command class, it is just not getting set
> (bind?). It returns an empty string.

Any exceptions?  Maybe a misspelling?  Does the log say anything? 
What is the name of your property?

Seth

Re: [Springframework-developer] new 'RedirectViewResolver'

[Seth L. <set...@gm...>]

> The whole point is that the view name still doesn't have any meaning to
> the controller. It's a logical identifier as far as the controller is
> concerned (the controller only deals in terms of names it gets as
> properties), but this is one mechanism for the resolving machinery to
> tell one target view from another.

Yes, good point.

If I read you correctly, it sounds like the controller is making the
decision to redirect or not.  You could set two view names into the
controller, and give them meaningful names.  The business logic in the
controller will chooses which view name to forward on to.  But the
words "redirect" are now left out.  The two view names you give to the
Controller are mapped normally.

Something like:

if (xxx) {
  return new ModelAndView("viewA");
} else if (XXX and YYY) {
  return new ModelAndView("viewB");
}

where:

viewA is JstlView
viewB is RedirectView

Not sure if that's cleaner, though.  It does remove any references to
redirecting inside the controller (both RedirectView and redirect: are
gone).

Seth

Re: [Springframework-developer] new 'RedirectViewResolver'

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

Seth Ladd wrote:

>On Wed, 28 Jul 2004 14:35:56 -0400, Colin Sampaleanu <col...@ex...> wrote:
>  
>
>>I'm working with an app (original source is not by me) that currently
>>has some pretty nasty view handling. It uses TilesJstlView, but for some
>>view properties the controller is actually aware that the view names
>>represent a need to redirect, and in those cases the controller returns
>>a new RedirectView it creates itself. I think this is pretty unclean.
>>Does anybody think it's worth having a new standard view resolver of
>>some sort that can be chained in front of other resolvers (such as in
>>this case TilesJstlViewResolver), and can recognize view names which
>>include a prefix meaning this is a redirect view? I.e.
>>RedirectViewResolver would recognize view names of the nature
>>  redirect:/some/external/path
>>and use a redirectView in that case? If they don't have the prefix, it
>>doesn't do anything and lets the next resolver get a whack at it.
>>
>>Another standard view resolver I could see being handy is a regex view
>>resolver, where there is a composite pattern being used. The resolver
>>has 1 to n other view resolvers registered with it, and for each one, a
>>regex. If there is a regex match, then it delegates to the view resoler
>>or chain of view resolvers set up for that regex.
>>    
>>
>
>Though I'm not in favor of a view name that has special meaning (I
>think view names should just be logical identifies), I do like the
>idea of a regex view resolver.
>  
>
The whole point is that the view name still doesn't have any meaning to 
the controller. It's a logical identifier as far as the controller is 
concerned (the controller only deals in terms of names it gets as 
properties), but this is one mechanism for the resolving machinery to 
tell one target view from another.

>I've also thought that a view resolver that can look at the Accept:
>header sent by the client would be useful sometimes.  It would be nice
>to do some content negotiation at the view resolving layer.  The view
>objects themselves would implement ContentNegotiable, and expose a
>public Map accepts() method (or some sort) that returns a map of
>content-type and the quality index.  The view name returned by the
>client is then used to find all views that match, and finds the best
>content type to serve the client.  Unfortunately, the ViewResolver
>interface doesn't know a thing about the HttpServletRequest (needed to
>get the Accept: headers).
>
>Seth
>  
>

Re: [Springframework-developer] Validation: multiple image buttons on forms

[Stefan D S. <ste...@us...>]

Seth,
Thanks for the reply, but since this is need as part of my validator, is
there not a way to get a hold of the request in the validator?

BTW - I have a property on the command class, it is just not getting set
(bind?). It returns an empty string.




Wednesday, July 28, 2004 8:35 PM
To: spr...@li...
cc:
From: Seth Ladd <set...@gm...>
Subject: Re: [Springframework-developer] Validation: multiple image buttons
on forms



If you don't want to make a property on the Command class, you can
always just look inside at the HttpServletRequest parameters (just
like you would before Spring/Struts/etc came along).  Many methods of
the Controller interface have access to the Request.

Seth



----- Original Message -----
From: Stefan D Sookraj <ste...@us...>
Date: Wed, 28 Jul 2004 18:12:45 -0400
Subject: [Springframework-developer] Validation: multiple image buttons on
forms
To: spr...@li...
Cc: spr...@li...


Hello,

I have this scenario:

<INPUT TYPE="image" SRC="/images/buttons/SUBMIT.png" VALUE="insert"
NAME="submit">
<INPUT TYPE="image" SRC="/images/buttons/DELETE.png" VALUE="delete"
NAME="submit">
<INPUT TYPE="image" SRC="/images/buttons/Cancel.png" VALUE="cancel"
NAME="submit">

and also tried this:

<INPUT TYPE="image" SRC="/images/buttons/BLUESUBMIT.png"
VALUE="insert" NAME="submit">
<INPUT TYPE="image" SRC="/images/buttons/DELETE.png" VALUE="delete"
NAME="delete">
<INPUT TYPE="image" SRC="/images/buttons/Cancel.png" VALUE="cancel"
NAME="cancel">

The problem I am getting is being able to determine which button was
pressed since the name property on these button do not bind to the
properties of the command object. How would I be able to determine
which button was pressed?

Additionally, I get <Data binding errors: 1> if this helps.
Using Spring 1.0.2



Thank you.


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
 https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Validation: multiple image buttons on forms

[Seth L. <set...@gm...>]

If you don't want to make a property on the Command class, you can
always just look inside at the HttpServletRequest parameters (just
like you would before Spring/Struts/etc came along).  Many methods of
the Controller interface have access to the Request.

Seth



----- Original Message -----
From: Stefan D Sookraj <ste...@us...>
Date: Wed, 28 Jul 2004 18:12:45 -0400
Subject: [Springframework-developer] Validation: multiple image buttons on forms
To: spr...@li...
Cc: spr...@li...

 
Hello, 
  
I have this scenario: 
  
<INPUT TYPE="image" SRC="/images/buttons/SUBMIT.png" VALUE="insert"
NAME="submit">
<INPUT TYPE="image" SRC="/images/buttons/DELETE.png" VALUE="delete"
NAME="submit">
<INPUT TYPE="image" SRC="/images/buttons/Cancel.png" VALUE="cancel"
NAME="submit">
  
and also tried this: 
  
<INPUT TYPE="image" SRC="/images/buttons/BLUESUBMIT.png"
VALUE="insert" NAME="submit">
<INPUT TYPE="image" SRC="/images/buttons/DELETE.png" VALUE="delete"
NAME="delete">
<INPUT TYPE="image" SRC="/images/buttons/Cancel.png" VALUE="cancel"
NAME="cancel">
  
The problem I am getting is being able to determine which button was
pressed since the name property on these button do not bind to the
properties of the command object. How would I be able to determine
which button was pressed?
  
Additionally, I get <Data binding errors: 1> if this helps. 
Using Spring 1.0.2 
  
  
  
Thank you.

Re: [Springframework-developer] new 'RedirectViewResolver'

[Seth L. <set...@gm...>]

On Wed, 28 Jul 2004 14:35:56 -0400, Colin Sampaleanu <col...@ex...> wrote:
> I'm working with an app (original source is not by me) that currently
> has some pretty nasty view handling. It uses TilesJstlView, but for some
> view properties the controller is actually aware that the view names
> represent a need to redirect, and in those cases the controller returns
> a new RedirectView it creates itself. I think this is pretty unclean.
> Does anybody think it's worth having a new standard view resolver of
> some sort that can be chained in front of other resolvers (such as in
> this case TilesJstlViewResolver), and can recognize view names which
> include a prefix meaning this is a redirect view? I.e.
> RedirectViewResolver would recognize view names of the nature
>   redirect:/some/external/path
> and use a redirectView in that case? If they don't have the prefix, it
> doesn't do anything and lets the next resolver get a whack at it.
> 
> Another standard view resolver I could see being handy is a regex view
> resolver, where there is a composite pattern being used. The resolver
> has 1 to n other view resolvers registered with it, and for each one, a
> regex. If there is a regex match, then it delegates to the view resoler
> or chain of view resolvers set up for that regex.

Though I'm not in favor of a view name that has special meaning (I
think view names should just be logical identifies), I do like the
idea of a regex view resolver.

I've also thought that a view resolver that can look at the Accept:
header sent by the client would be useful sometimes.  It would be nice
to do some content negotiation at the view resolving layer.  The view
objects themselves would implement ContentNegotiable, and expose a
public Map accepts() method (or some sort) that returns a map of
content-type and the quality index.  The view name returned by the
client is then used to find all views that match, and finds the best
content type to serve the client.  Unfortunately, the ViewResolver
interface doesn't know a thing about the HttpServletRequest (needed to
get the Accept: headers).

Seth