springframework-developer — Spring Framework developers list

RE: [Springframework-developer] Commons-Validator for Spring

[Daniel M. <mi...@pa...>]

Thanks for your feedback Sam.

I agree. I will talk to the Struts developers about what I'm doing before I
include their code into the Spring project.

I was also leaning toward a tag library. Does anyone have input on whether
another tag should be added to the Spring taglib or should it be a totally
separate taglib (just for javascript validation)?

Thanks.
Daniel

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Sam Newman
Sent: Monday, March 08, 2004 5:42 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Commons-Validator for Spring


Daniel Miller wrote:
> To all,
>
> I am looking into implementing the JavaScript portion of the
> Commons-Validator for Spring. I have a few questions on which I would
> appreciate some feedback:
>
> 1. Rather than re-invent the wheel I was planning on using as much
existing
> code as possible to implement JavaScript validation for Spring. It turns
out
> that the Struts source contains a lot of the code that "constructs" the
> JavaScript functions for the client. What are the policies for using code
> from other open-source projects in Spring? Can I just rip a bunch of code
> out of the Struts source and adapt it for Spring? Do I need to ask
> permission first?

No matter what the license says, I think it would be advisable to ask -
some goodwill from the struts developers might well help the process. In
fact the struts developers are known to be a big fan of their code being
rebuilt as separate modules - the Jakarta commons projects started from
code in struts 1.0 being moved into separate projects. Struts is
licensed using the Apache license, as such their code can be used
without problem as long as correct attribution is given - this amounts
to stating in the code itself and the documentation where it came from.

> 3. Would it be advisable to put the javascript generating code in the tag
> library or in the ValidatorFactory (which holds the resources needed to
> build the code; things like message resources would need to be passed in)?

A tag library would be my preferred choice (I hate Java scriptlets in
JSP pages - a maintenance nightmare) although I suspect that the tag
would be a relatively thin wrapper over the ValidatorFactory itself.

--
sam
http://www.magpiebrain.com/


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Commons-Validator for Spring

[Daniel M. <mi...@pa...>]

Seth,

Your first request: make it work with XHTML 1.0 Strict
I'll have to look into that, but I doubt that I can make that change. I
think you better go ask the developers of the commons-validator to do that.
By the way, I expect JavaScript support to be better once the next version
of the commons-validator comes out. It looks like the developers have spent
more time integrating the JavaScript validation into the picture. However,
it doesn't seem like there's much going on in the way of new development for
the commons-validator. It seems like the developers are waiting on something
(Struts 1.2 or 1.3??).

Second: Only included the necessary JavaScript
I know exactly what you mean. It makes for a huge glob of extra code that is
mostly unneeded, which only makes your page size a lot bigger. I was hoping
to only include the required functions, but I'm not sure how easy it would
be to do. The code (from Struts) that constructs the JavaScript code does
not look like it has been optimized.

I have been testing my current implementation and can verify that it works,
with the exception of the MessageResourceResolvable patch for the Spring
core. Once that is out, I will package my validator in a jar (it really
doesn't have any other major dependencies), and put it out for people to
try. I am very pleased with how easy it is to add validation to any
project--just simply add the ValidatorFactory and BeanValidator definitions
in the AppContext, write your validation rules in validation.xml, add the
corresponding message resources, and use the BeanValidator to validate your
bean, it's really that simple.

Daniel


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Seth Ladd
Sent: Monday, March 08, 2004 1:10 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Commons-Validator for Spring


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Miller wrote:
| To all,
|
| I am looking into implementing the JavaScript portion of the
| Commons-Validator for Spring. I have a few questions on which I would
| appreciate some feedback:

Daniel,

This is great to see!  I have a few requests:

- - Make the javascript work with XHTML 1.0 Strict or >.  Currently,
Struts' javascript works with a <form> with a name attribute.  The name
attribute is deprecated.  It's id now.

- - Selectively include the javascript functions being used on the form.
In Struts right now, if you choose to include Javascript validation, it
includes every possible function.


Good luck, and I'd love to help test it out.  Keith has been working on
some new APIs for validation, so they might be helpful.  I think they
are either in the RCP or sandbox.

Seth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFATLcI5EIB1scRes8RAiTRAJ4yg5FaX7YMcTIHKjSybVH1WB3jqwCeLDyZ
AJlkNlE1xImEtQlfEXYeqeE=
=mC24
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Road map (security)

[Ben A. <ben...@ac...>]

I agree there is value in allowing the Acegi security project to develop and
see where it leads for now. One question: should I establish a separate SF
mailing list or is there any objection in using springframework-developer
and spring-user for now? I doubt there will be much traffic and it will be
easier to solicit feedback from those not actively using it.

At this time I'm really focusing on Spring. Thus the project name has "for
Spring" at the end. It wouldn't be too hard to get the Acegi security
project supporting non-Spring containers, but doing so at this early stage
would dilute the focus of the project. I'm not even sure what the status is
of other IoC containers and security - do they already have it? If so, we
wouldn't bother. If not, security could be a differentiation factor for
Spring. I'd welcome other views on this.

> Actually, at the moment we're not doing everything that's out 
> there. One of those things is declarative security. I really 
> think it should be addressed in some way. Some people just 
> don't see Spring as suitable for enterprise apps, because of 
> lack of security infrastructure (this is the main reason for 
> some applications we're still using EJBs, arggghhhh, I hate it!).

The only argument I can think of against Spring's security support today is
the low installed base of the Acegi security project. Conversely, the code
is simple, with reasonable test coverage and easily reviewed. The Acegi
security project certainly provides plenty of features and plug-in points. A
major benefit is that it complements the existing container security
capabilities via the included "container adapters". This has a number of
benefits:

* Appeals to users who want to build on their understanding of J2EE
declarative security
* Your container obtains the authentication credentials from the user (form,
basic auth etc)
* Normal declarative security can be used to secure EJB, Servlets, JSPs,
static content etc
* The Acegi security approach complements future security enhancement of
J2EE specs
* It immediately works out-of-the-box, which is always encouraging to new
users
* You can still use the "alternative approach" (discussed below)

The "alternative approach" is to ignore container adapters. That is, you
populate your Authentication object in a Session (probably via a form), and
write your own handler for securing static content etc (like a
HttpRequestPathAuthorizationFilter). The price of this is ignoring container
capabilities and the J2EE specs. Still, you can easily do that using the
Acegi approach. Or you can do it the recommended way via container adapters.

Cheers

Ben

Re: [Springframework-developer] Road map (security)

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

BTW, I'm quite impressed with what you've achieved already (as I told =
you in a private mail a couple of days ago). And it definitely has some =
of the best documentation that I've ever seen in a 0.1 release! :-)
=20
Keep up the good work!
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Do 11.03.2004 23:00
An: spr...@li...
Betreff: Re: [Springframework-developer] Road map (security)



Ben,

I've indeed not included daughter respectively sister projects like RCP =
and security  in the road map. Those are complex enough to be hosted as =
separate projects, with separate release cycles and separate road map. =
My mail just focussed on the road map of the Spring core. Of course, the =
road maps should be aligned to a certain degree.

I'm delighted to see all the work that you put into your security =
system, and also to see the interest in it. As we discussed in private =
mails before, the final word on standard Spring security support is not =
out yet: Actually, there might never be standard Spring security but =
just very basic hooks in the framework that all for easy integration of =
separate products like the Acegi Security System.

Security requirements can be complex and vary widely, so I do see the =
value of letting separate security products evolve independently. I take =
a pragmatic stance here: Let's see how things evolve.  We will of course =
link to your project from the Spring website, referring to it as a =
security system for Spring, with focus on integration with J2EE =
container security. Feel free to suggest to an appropriate tagline :-)

Regarding hosting, I don't have a strong opinion on separate SourceForge =
projects versus separate modules within the main Spring project. My =
basic guideline is: If it's closely integrated with the Spring core but =
still worth a separate project, then a module within the main Spring =
project is appropriate, like in the case of RCP and the Eclipse beans =
plugin. The Acegi Security System is probably more generic here.

Persistence solutions like Hibernate and iBATIS SQL Maps are separate =
projects but integrate nicely with Spring; the same applies to web =
frameworks like Struts and WebWork. So I wouldn't be surprised to see =
cross-cutting add-ons like security systems evolve in a similar fashion, =
particularly if they allow for standalone usage outside of a full Spring =
context as well. It's good to see Spring create an ecosystem here :-)

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Ben Alex
Gesendet: Do 11.03.2004 21:40
An: spr...@li...
Betreff: RE: [Springframework-developer] Road map (security)



> How about declarative security, should somehow also be
> mentioned in the roadmap. Any ideas so far about how to go about it?

Thought I'd jump in here. The Acegi Security System for Spring project =
now
has a home at SoureForge. I'm currently writing automated container
integration unit tests (ie unzip a stock standard container release, =
install
the security module to it, and run unit tests). CVS and a new ZIP =
release
will be at SourceForge in a day or two, and anyone interested is welcome =
to
participate in development.

Whilst I initially wrote the above project with a view to inclusion in
Spring, I also recognise there are no Spring-specific dependencies apart
from standard bean context and interceptor services. As such, from a
technical perspective security could be effectively developed in a =
separate
project, or as a separate module under Spring CVS. There is no technical
requirement in having it in Spring core. The real issue is whether from =
a
marketing perspective the Spring Framework needs its very own security
capability/project, an "official" separate security project that users =
are
pointed towards, or a list of external (untested) security projects that
claim to support Spring.

It would be nice to avoid duplication of efforts on security, =
particularly
given most of it involves writing adapters between the project security =
and
the container's native security. Maximising the user and developer base =
of a
single security project will also have obvious benefits in terms of =
testing,
issue identification, support and improvement.

Ben



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] add mutators to ModelAndView ?

[Alef A. <al...@jt...>]

I've added a JIRA issue yesterday about such behavior. We're having a
mapping from logical view names to actual views now, but in my opinion =
there
should be another abstraction there, like you're saying to for instance
allow one controller to have both a PDF view and an HTML view...

I don't know whether or not adding mutators to the ModelAndView would do =
the
trick...

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of Darren Davison
> Sent: Thursday, March 11, 2004 3:05 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] add mutators to ModelAndView =
?
>=20
>=20
>=20
> > We have a concrete requirement to be able to override a viewname
> selected
> > by a controller in a postHandle() method of an interceptor.
>=20
> having woken up now and put a little thought into this, I can handle =
my
> immediate requirements elegantly enough within the existing framework.
> Specifying model attributes to override velocity subtemplates will do =
the
> trick - it just needs some reworking of the top-level templates =
themselves
> mostly.
>=20
> I don't know whether the proposal may still be of use if someone had a
> real need to override the entire view though (say to change from an =
html
> based view to a PDF/Excel one).  I could see that type of thing as =
still
> being a possible requirement that would require mutators on =
ModelAndView.
>=20
> Regards,
>=20
> --
> Darren Davison
> Public Key: http://www.davison.uk.net/key.jsp
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Road map (security)

[Alef A. <al...@jt...>]

First of all I must say I forget about you Ben and I really have to take a
look at your code soon! I just downloaded it...

Our proposition is: easier J2EE.

Actually, at the moment we're not doing everything that's out there. One of
those things is declarative security. I really think it should be addressed
in some way. Some people just don't see Spring as suitable for enterprise
apps, because of lack of security infrastructure (this is the main reason
for some applications we're still using EJBs, arggghhhh, I hate it!).

Colin, you're right about varying requirements. The question is: are
role-based security and method-level restrictions enough. Well, I have been
able to build decent apps with that, so I would say: yes. Unfortunately
there are no decent common grounds on which all servlet containers base
their security (like JTA), so that I guess, is the real problem.

Alef

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Colin Sampaleanu
> Sent: Thursday, March 11, 2004 10:36 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Road map (security)
> 
> Ben Alex wrote:
> 
> >>How about declarative security, should somehow also be
> >>mentioned in the roadmap. Any ideas so far about how to go about it?
> >>
> >>
> >
> >Thought I'd jump in here. The Acegi Security System for Spring project
> now
> >has a home at SoureForge. I'm currently writing automated container
> >integration unit tests (ie unzip a stock standard container release,
> install
> >the security module to it, and run unit tests). CVS and a new ZIP release
> >will be at SourceForge in a day or two, and anyone interested is welcome
> to
> >participate in development.
> >
> >Whilst I initially wrote the above project with a view to inclusion in
> >Spring, I also recognise there are no Spring-specific dependencies apart
> >from standard bean context and interceptor services. As such, from a
> >technical perspective security could be effectively developed in a
> separate
> >project, or as a separate module under Spring CVS. There is no technical
> >requirement in having it in Spring core. The real issue is whether from a
> >marketing perspective the Spring Framework needs its very own security
> >capability/project, an "official" separate security project that users
> are
> >pointed towards, or a list of external (untested) security projects that
> >claim to support Spring.
> >
> >It would be nice to avoid duplication of efforts on security,
> particularly
> >given most of it involves writing adapters between the project security
> and
> >the container's native security. Maximising the user and developer base
> of a
> >single security project will also have obvious benefits in terms of
> testing,
> >issue identification, support and improvement.
> >
> >Ben
> >
> >
> Ben,
> 
> Your stuff looks great. I'm probably going to try using it in our main
> app in the relatively near-term (a month or so). I _really_ appreciate
> the work you've put into it.
> 
> At the same time, due to the fact the people's security needs are so
> varied, it might be a bit preliminary to bake it into Spring itself
> without letting people use it for a while, hopefully with the idea that
> any relevant comments or issues would be raised in the process. Once
> something is part of Spring itself it's going to be much harder to make
> backwards incompatible changes, whereas with an external add-on, there
> could simply be two versions. Just IMHO...
> 
> Regards,
> Colin
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Road map (security)

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

Ben,
=20
I've indeed not included daughter respectively sister projects like RCP =
and security  in the road map. Those are complex enough to be hosted as =
separate projects, with separate release cycles and separate road map. =
My mail just focussed on the road map of the Spring core. Of course, the =
road maps should be aligned to a certain degree.
=20
I'm delighted to see all the work that you put into your security =
system, and also to see the interest in it. As we discussed in private =
mails before, the final word on standard Spring security support is not =
out yet: Actually, there might never be standard Spring security but =
just very basic hooks in the framework that all for easy integration of =
separate products like the Acegi Security System.
=20
Security requirements can be complex and vary widely, so I do see the =
value of letting separate security products evolve independently. I take =
a pragmatic stance here: Let's see how things evolve.  We will of course =
link to your project from the Spring website, referring to it as a =
security system for Spring, with focus on integration with J2EE =
container security. Feel free to suggest to an appropriate tagline :-)=20
=20
Regarding hosting, I don't have a strong opinion on separate SourceForge =
projects versus separate modules within the main Spring project. My =
basic guideline is: If it's closely integrated with the Spring core but =
still worth a separate project, then a module within the main Spring =
project is appropriate, like in the case of RCP and the Eclipse beans =
plugin. The Acegi Security System is probably more generic here.
=20
Persistence solutions like Hibernate and iBATIS SQL Maps are separate =
projects but integrate nicely with Spring; the same applies to web =
frameworks like Struts and WebWork. So I wouldn't be surprised to see =
cross-cutting add-ons like security systems evolve in a similar fashion, =
particularly if they allow for standalone usage outside of a full Spring =
context as well. It's good to see Spring create an ecosystem here :-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Ben Alex
Gesendet: Do 11.03.2004 21:40
An: spr...@li...
Betreff: RE: [Springframework-developer] Road map (security)



> How about declarative security, should somehow also be
> mentioned in the roadmap. Any ideas so far about how to go about it?

Thought I'd jump in here. The Acegi Security System for Spring project =
now
has a home at SoureForge. I'm currently writing automated container
integration unit tests (ie unzip a stock standard container release, =
install
the security module to it, and run unit tests). CVS and a new ZIP =
release
will be at SourceForge in a day or two, and anyone interested is welcome =
to
participate in development.

Whilst I initially wrote the above project with a view to inclusion in
Spring, I also recognise there are no Spring-specific dependencies apart
from standard bean context and interceptor services. As such, from a
technical perspective security could be effectively developed in a =
separate
project, or as a separate module under Spring CVS. There is no technical
requirement in having it in Spring core. The real issue is whether from =
a
marketing perspective the Spring Framework needs its very own security
capability/project, an "official" separate security project that users =
are
pointed towards, or a list of external (untested) security projects that
claim to support Spring.

It would be nice to avoid duplication of efforts on security, =
particularly
given most of it involves writing adapters between the project security =
and
the container's native security. Maximising the user and developer base =
of a
single security project will also have obvious benefits in terms of =
testing,
issue identification, support and improvement.

Ben



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Road map (security)

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

Ben Alex wrote:

>>How about declarative security, should somehow also be 
>>mentioned in the roadmap. Any ideas so far about how to go about it?
>>    
>>
>
>Thought I'd jump in here. The Acegi Security System for Spring project now
>has a home at SoureForge. I'm currently writing automated container
>integration unit tests (ie unzip a stock standard container release, install
>the security module to it, and run unit tests). CVS and a new ZIP release
>will be at SourceForge in a day or two, and anyone interested is welcome to
>participate in development.
>
>Whilst I initially wrote the above project with a view to inclusion in
>Spring, I also recognise there are no Spring-specific dependencies apart
>from standard bean context and interceptor services. As such, from a
>technical perspective security could be effectively developed in a separate
>project, or as a separate module under Spring CVS. There is no technical
>requirement in having it in Spring core. The real issue is whether from a
>marketing perspective the Spring Framework needs its very own security
>capability/project, an "official" separate security project that users are
>pointed towards, or a list of external (untested) security projects that
>claim to support Spring.
>
>It would be nice to avoid duplication of efforts on security, particularly
>given most of it involves writing adapters between the project security and
>the container's native security. Maximising the user and developer base of a
>single security project will also have obvious benefits in terms of testing,
>issue identification, support and improvement.
>
>Ben
>  
>
Ben,

Your stuff looks great. I'm probably going to try using it in our main 
app in the relatively near-term (a month or so). I _really_ appreciate 
the work you've put into it.

At the same time, due to the fact the people's security needs are so 
varied, it might be a bit preliminary to bake it into Spring itself 
without letting people use it for a while, hopefully with the idea that 
any relevant comments or issues would be raised in the process. Once 
something is part of Spring itself it's going to be much harder to make 
backwards incompatible changes, whereas with an external add-on, there 
could simply be two versions. Just IMHO...

Regards,
Colin

RE: [Springframework-developer] Road map (security)

[Ben A. <ben...@ac...>]

> How about declarative security, should somehow also be 
> mentioned in the roadmap. Any ideas so far about how to go about it?

Thought I'd jump in here. The Acegi Security System for Spring project now
has a home at SoureForge. I'm currently writing automated container
integration unit tests (ie unzip a stock standard container release, install
the security module to it, and run unit tests). CVS and a new ZIP release
will be at SourceForge in a day or two, and anyone interested is welcome to
participate in development.

Whilst I initially wrote the above project with a view to inclusion in
Spring, I also recognise there are no Spring-specific dependencies apart
from standard bean context and interceptor services. As such, from a
technical perspective security could be effectively developed in a separate
project, or as a separate module under Spring CVS. There is no technical
requirement in having it in Spring core. The real issue is whether from a
marketing perspective the Spring Framework needs its very own security
capability/project, an "official" separate security project that users are
pointed towards, or a list of external (untested) security projects that
claim to support Spring.

It would be nice to avoid duplication of efforts on security, particularly
given most of it involves writing adapters between the project security and
the container's native security. Maximising the user and developer base of a
single security project will also have obvious benefits in terms of testing,
issue identification, support and improvement.

Ben

Re: [Springframework-developer] Road map

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

Keith,

My proposal is by no means a strict plan: If JMX doesn't get stable in =
time, we'll release 1.1 with "just" JMS support and declarative =
validation. JMX could then go into release 1.2, depending on when we =
consider it ready.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Keith Donald
Sent: Thursday, March 11, 2004 4:18 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Road map


The end of April sounds reasonable for JMX support and the declarative
validation.

Most of the validation design/coding is already complete (though we =
still
need more rules, more tests/feedback, and better docs.)

The JMX stuff is obviously more work and presents more issues to =
consider,
but I still think the end of April works for base JMX support =
(jmx-enabling
spring beans.)  Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: Thursday, March 11, 2004 9:24 AM
To: spr...@li...
Subject: [Springframework-developer] Road map


Everybody,

As we agree to do quick 1.1/1.2/etc releases, we need to prioritize the
feature requests in our Jira now. I suggest to target the following:

1.0 final (March 20th)
* AOP Alliance update
* FreeMarker support

1.1 RC1 (end of April)
* JMS support
* JMX support
* declarative rules-based validator
* minor enhancements to the web framework

1.1 final (late May)

1.2 RC1 (end of June)
* OGNL support
* JCA support
* enhanced RMI support
* enhanced PropertiesBeanDefinitionReader

1.2 final (late July)

1.3 RC1
* support for JDK 1.5 metadata?
* Prevayler support?
* JdoDialects for major JDO implementations?
* Spring/JDO sample application?

Keith et al, do you think you can finish JMX and declarative validation =
in
time? Anyone willing to work on OGNL support and give an estimate?

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

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


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Road map

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

> 1.0 final (March 20th)
> * FreeMarker support

that's fine.

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

RE: [Springframework-developer] Road map

[Alef A. <al...@jt...>]

How about declarative security, should somehow also be mentioned in the
roadmap. Any ideas so far about how to go about it?

Alef

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of j=FCrgen h=F6ller [werk3AT]
> Sent: Thursday, March 11, 2004 3:24 PM
> To: spr...@li...
> Subject: [Springframework-developer] Road map
>=20
> Everybody,
>=20
> As we agree to do quick 1.1/1.2/etc releases, we need to prioritize =
the
> feature requests in our Jira now. I suggest to target the following:
>=20
> 1.0 final (March 20th)
> * AOP Alliance update
> * FreeMarker support
>=20
> 1.1 RC1 (end of April)
> * JMS support
> * JMX support
> * declarative rules-based validator
> * minor enhancements to the web framework
>=20
> 1.1 final (late May)
>=20
> 1.2 RC1 (end of June)
> * OGNL support
> * JCA support
> * enhanced RMI support
> * enhanced PropertiesBeanDefinitionReader
>=20
> 1.2 final (late July)
>=20
> 1.3 RC1
> * support for JDK 1.5 metadata?
> * Prevayler support?
> * JdoDialects for major JDO implementations?
> * Spring/JDO sample application?
>=20
> Keith et al, do you think you can finish JMX and declarative =
validation in
> time? Anyone willing to work on OGNL support and give an estimate?
>=20
> Juergen
>=20
>=20
> DI J=FCrgen H=F6ller
> Senior System Architect
> ______________________________________
>=20
> werk3ATS - division systementwicklung
> werk3AT informations- und mediensysteme
>=20
> europaplatz 4
> A - 4020 linz
>=20
> t.  +43 (0) 732 71 65 29 502
> f.  +43 (0) 732 71 65 29 3
> mailto:jue...@we...
> http://www.werk3at.com
> ______________________________________
> werk3ATS - WIR ENTWICKELN ERFOLG
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] FieldError: TypeMismatch - generic message

[Daniel M. <dm...@tc...>]

Is there a way to specify a generic message for a single type on type
mismatch for FieldErrors? For example I would like to define a message
resource like this:

typeMismatch.integer=3DValue must be an integer
or
typeMismatch.com.example.SomeType=3DValue must be a valid identifier for
SomeType

The second woule be optimal (for types with matching names, but in
different packages). Currently I have to do this for each field:

typeMismatch.objectName.fieldName=3DField on Object must be [sometype]
or
typeMismatch.fieldName=3DField must be [sometype]

In my opinion, that is severely limiting. I must at least specify a
message resource for each and every field that is not a string. Granted,
my message could apply to multiple fields if I happened to have two
objects with the same field name, but I think this would be more prone
to displaying the wrong message for a field of a different type that
happened to have the same name.

While I'm on the subject, I might as well vent my other peeve with this
message name construction pattern. Why have typeMismatch be the "parent"
element in the message name? Wouldn't it be more logical to have the
message signature be "objectName.fieldName.code"? I think this is a flaw
in the Spring-centric method of message resource resolution. I would
expect the error messages to be resolved in the following order:

Most specific (first)

objectName.fieldName.typeMismatch
objectName.typeMismatch.typeName
objectName.typeMismatch
typeMismatch.typeName
typeMismatch

Least specific (last)

That way the name is resolved from first to last: field on object
(implied type) to type on object (could be nice) to object mismatch (I
would rarely if ever use this) to mismatch for type (very useful) to
typeMismatch (to keep all unhandled mismatch messages nice and
user-friendly). Note that "typeMismatch" is a code that would need extra
"arguments" (typeName), while the "required" code wouldn't necessarily
need the type. However, it wouldn't hurt to have the same type of
message resolution pattern. Who cares if it looks for a message with the
name "objectName.required.java.lang.Integer" or
"required.java.lang.Integer"? Most people would simply not define those
messages.

I realize that the changes suggested here are revolutionary, but I think
it is imperative to make the change as soon as possible (pre-1.0) to
have minimal frustration in the future as Spring becomes more widely
used.

Thanks,
Daniel Miller

RE: [Springframework-developer] Road map

[Keith D. <kd...@cs...>]

The end of April sounds reasonable for JMX support and the declarative
validation.

Most of the validation design/coding is already complete (though we =
still
need more rules, more tests/feedback, and better docs.)

The JMX stuff is obviously more work and presents more issues to =
consider,
but I still think the end of April works for base JMX support =
(jmx-enabling
spring beans.)  Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: Thursday, March 11, 2004 9:24 AM
To: spr...@li...
Subject: [Springframework-developer] Road map


Everybody,

As we agree to do quick 1.1/1.2/etc releases, we need to prioritize the
feature requests in our Jira now. I suggest to target the following:

1.0 final (March 20th)
* AOP Alliance update
* FreeMarker support

1.1 RC1 (end of April)
* JMS support
* JMX support
* declarative rules-based validator
* minor enhancements to the web framework

1.1 final (late May)

1.2 RC1 (end of June)
* OGNL support
* JCA support
* enhanced RMI support
* enhanced PropertiesBeanDefinitionReader

1.2 final (late July)

1.3 RC1
* support for JDK 1.5 metadata?
* Prevayler support?
* JdoDialects for major JDO implementations?
* Spring/JDO sample application?

Keith et al, do you think you can finish JMX and declarative validation =
in
time? Anyone willing to work on OGNL support and give an estimate?

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

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


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Road map

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

j=FCrgen h=F6ller [werk3AT] wrote:

>Everybody,
>
>As we agree to do quick 1.1/1.2/etc releases, we need to prioritize the =
feature requests in our Jira now. I suggest to target the following:
>
>1.0 final (March 20th)
>* AOP Alliance update
>* FreeMarker support
>
>1.1 RC1 (end of April)
>* JMS support
>* JMX support
>* declarative rules-based validator
>* minor enhancements to the web framework
>
>1.1 final (late May)
>
>1.2 RC1 (end of June)
>* OGNL support
>* JCA support
>* enhanced RMI support
>* enhanced PropertiesBeanDefinitionReader
>
>1.2 final (late July)
>
>1.3 RC1
>* support for JDK 1.5 metadata?
>* Prevayler support?
>* JdoDialects for major JDO implementations?
>* Spring/JDO sample application?
>
>Keith et al, do you think you can finish JMX and declarative validation =
in time? Anyone willing to work on OGNL support and give an estimate?
>
>Juergen
> =20
>
I should be able to do the OGNL support in that timeframe. The last 6=20
weeks or so have been really bad for me, with basically no free time at=20
all, and this will continue for another couple of weeks, but there=20
should be no problem working on it in the timeframe above...

Regards,
Colin

[Springframework-developer] Road map

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

Everybody,

As we agree to do quick 1.1/1.2/etc releases, we need to prioritize the =
feature requests in our Jira now. I suggest to target the following:

1.0 final (March 20th)
* AOP Alliance update
* FreeMarker support

1.1 RC1 (end of April)
* JMS support
* JMX support
* declarative rules-based validator
* minor enhancements to the web framework

1.1 final (late May)

1.2 RC1 (end of June)
* OGNL support
* JCA support
* enhanced RMI support
* enhanced PropertiesBeanDefinitionReader

1.2 final (late July)

1.3 RC1
* support for JDK 1.5 metadata?
* Prevayler support?
* JdoDialects for major JDO implementations?
* Spring/JDO sample application?

Keith et al, do you think you can finish JMX and declarative validation =
in time? Anyone willing to work on OGNL support and give an estimate?

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

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

Re: [Springframework-developer] add mutators to ModelAndView ?

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

> We have a concrete requirement to be able to override a viewname select=
ed
> by a controller in a postHandle() method of an interceptor.

having woken up now and put a little thought into this, I can handle my
immediate requirements elegantly enough within the existing framework.=20
Specifying model attributes to override velocity subtemplates will do the
trick - it just needs some reworking of the top-level templates themselve=
s
mostly.

I don't know whether the proposal may still be of use if someone had a
real need to override the entire view though (say to change from an html
based view to a PDF/Excel one).  I could see that type of thing as still
being a possible requirement that would require mutators on ModelAndView.

Regards,

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

[Springframework-developer] BeanWrapperImpl - setting indexed properties

[Choy R. <ch...@ny...>]

Something was posted on the user list about easy Map property support
from the web framework. I assumed it would simply be a matter of naming
the request parameters "map[key]" and the bean wrapper would handle the
rest. So I tested my assumption out with something like

MapBean tb = new MapBean();
BeanWrapper bw = new BeanWrapperImpl( tb );
bw.setPropertyValue("map[key1]","value1");
assertEquals("value1", tb.getMap().get("key1") );

well, to my surprise, it doesn't get past setPropertyValue(). It's not
terrible. But since getPropertyValue("map[key1]") works, one would
expect setPropertyValue to work also.

I looked over the BeanWrapperImpl code and hacked some changes which
I've included in a patch. All the tests in BeanWrapperTestSuite still
pass.

The patch is just a hack. BeanWrapperImpl would probably need to be
refactored a bit before adding a production quality version of this
feature.

[Springframework-developer] add mutators to ModelAndView ?

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

We have a concrete requirement to be able to override a viewname selected
by a controller in a postHandle() method of an interceptor.  Specifically
it's for defining potentially very different views for very different
device types that may be accessing the resources.

Ideally I don't want myriad controllers to care what the client device is=
,
so I want to use an interceptor to suffix the viewname before the
dispatcher resolves it.  The interceptor can then be quite flexible -
providing bean properties to specify which request header to look in and
one to specify a regular expression to pattern match against.

I can't retrieve the View from the MAV and set, say, a different Velocity
template name, or JSP location, or XSLT stylesheet and unfortunately,
there's no setView() or setViewName() in the immutable ModelAndView class
which would seem to be the easiest and most obvious fix.

What would the issues be in adding them?

Alternatively, is there another or better way to meet this use case?

Regards,
--=20
Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

Re: [Springframework-developer] FreeMarker for 1.0 ?

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

> I'm the one who changed it from minor to major :-) As we are indeed aim=
ing
> for March 20th, there should be no problem moving the FreeMarker suppor=
t
> to the main source tree. Backward-compatible enhancement can always go =
in
> in 1.0.1 or 1.1 etc.

ok.  I've already made all the relevant changes locally, including
freemarker-2.3rc1 which has indeed now been released.  I'll commit
everything tonight.

Regards,
--=20
Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

[Springframework-developer] Re: Spring transaction management with TopLink

[Andreas S. <eo...@gm...>]

Since the original issue resolved to be an application bug :-( I'd
nonetheless like to describe how I managed to achieve the TopLink integration for my
case. Maybe someone else is interested in this.

I've had a look at the Hibernate approach described by Jürgen. However it is
not fitting for me for the reason, that I'm not using standalone TopLink.
Rather TopLink is configured to be integrated on a JTS level into BEA WebLogic.
That means, WebLogic's JTA uses TopLink transactions under the hood.

The reason to extend JtaTransactionManager was therefore only, to have a
central point to access the active UnitOfWork for actually doing some
persistence-related work.

The approach is then as follows:

1.  Extend initialization to create a TopLink Session
2.  override lookupUserTransaction(). There I get the UserTransaction from
the superclass and return a wrapper around it which handles the assignment of
the active UnitOfWork in begin, commit and rollback. Additionally the Wrapper
class provides a means to retrieve the UnitOfWork.

The usage is then to assign the transaction manager declaratively to the DAO
which can then retrieve the active UnitOfWork to do its work. Actually the
transaction manager is passed only via an additional interface to prevent the
DAO implementation from meddling with transaction handling.

And finally: everything works so far.

Regards,
Andreas

P.S.: I'm rather sceptical about frameworks, but spring is really great.

Re: [Springframework-developer] FreeMarker for 1.0 ?

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

I'm the one who changed it from minor to major :-) As we are indeed =
aiming for March 20th, there should be no problem moving the FreeMarker =
support to the main source tree. Backward-compatible enhancement can =
always go in in 1.0.1 or 1.1 etc.
=20
I'm going to commit some enhancements to =
ReloadableResourceBundleMessageSource today, allowing to read properties =
files with specific charsets, and decoupling it from an =
ApplicationContext through the introduction of a ResourceLoader =
interface (for standalone usage).
=20
Else, I'm done from my point of view. The only remaining thing that I'm =
aware of is an update of AOP Alliance: Rod is working on this with a =
target deadline of mid next week, so that should still fit with a March =
20th release.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Darren Davison
Gesendet: Mi 10.03.2004 20:43
An: spr...@li...
Betreff: [Springframework-developer] FreeMarker for 1.0 ?



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I notice the FreeMarker integration status in JIRA has been changed from
Minor to Major.. given that the FM boys are releasing RC1 tonight
(apparantly) I'm happy to move this from the sandbox to the main tree as
soon as I can get a copy of it.  Anyone have any objections?  As far as =
I'm
concerned, what's written works well but there may be a need for some
updates such as making Template beans available.

Over the next couple of days I'll make a couple of small planned
enhancements to it, fix the javadoc and add it to the reference
documentation.

Do we have a firm date in mind yet for 1.0-final?  Are we aiming for the
20th (1st day of Spring as - I think - Thomas pointed out) ?

Regards,
- --

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAT3AAKLMLAN01aw0RAvgRAJ4y6MflX6UjkO2qmnMTaIz2Bo/ocACfb7XD
czy7iDY37cIge2ISqqeYLqQ=3D
=3DksZ8
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] declarative rules-based bean validator w/ attributes in sandbox

[Keith D. <kd...@cs...>]

Anna,

Thanks... yea, I typed that by hand in the email from memory and I see I
made at least one mistake with a closing tag in the first bean declaration.
:-) I'll be sure to correct anything like that when we get some samples/docs
out.

BTW, guys thanks for those commons attributes tips.  I haven't had time to
go through their docs in detail and I really appreciate it.  I agree we
should keep the validation rule hierarchy as is.

Keith

----- Original Message ----- 
From: "Anna Chen" <ac...@er...>
To: <spr...@li...>
Sent: Wednesday, March 10, 2004 4:04 PM
Subject: RE: [Springframework-developer] declarative rules-based bean
validator w/ attributes in sandbox


> Keith
>
> I don't think that the Spring IoC configuration is a valid one according
to
> http://www.springframework.org/dtd/spring-beans.dtd
>
>
> Anna
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Keith Donald
> Sent: Wednesday, March 10, 2004 8:10 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] declarative rules-based bean
> validator w/ attributes in sandbox
>
>
> Correct me if I'm wrong, but I don't think there is.  However, I know if
> you're using Eclipse, the sandbox code (including tests) automatically
gets
> incrementally compiled in target/other-classes, which is automatically put
> in the classpath.  So I have been basically running everything in the
> sandbox from Eclipse directly.
>
> Keith
>
> ----- Original Message -----
> From: <sam...@ma...>
> To: <spr...@li...>
> Sent: Wednesday, March 10, 2004 6:42 AM
> Subject: RE: [Springframework-developer] declarative rules-based bean
> validator w/ attributes in sandbox
>
>
> > Excellent, thanks Keith. On the subject of the sandbox, is there a build
> > directive to buils the sandbox code, or should I just overwrite the src
> with the
> > sandbox code and rebuild?
> >
> > sam
> >
> > Quoting Keith Donald <kd...@cs...>:
> >
> > > I checked in a "BeanValidatorBuilder" class in the sandbox under
> > > validation.support that allows you to declaratively assign
> > > PropertyValidationRules to bean properties via Spring-IoC, through a
> > > scripting environment such as Groovy/Beanshell, or programatically in
=
> > > plain
> > > java.  This is in addition to support for defining validation rules on
=
> > > beans
> > > via source markup.
> > >
> > > Here's an example on how to use it:
> > >
> > > Spring IoC configuration
> > >
> > > <bean id=3D"validatorBuilder"
> > > class=3D"org.springframework.validation.support.ValidatorBuilder"/>
> > > <constructor-arg index=3D"0">
> > > <description>The validated bean type (class or
> > > interface) aka 'root entity'</description>
> > > <value>org.springframework.validation.Pet</value>
> > > </constructor-arg>
> > > <map>
> > > <description>
> > > A map of property name keys to one or more
> > > governing property validation rules.
> > > Nested bean property names from the 'root
> > > entity' are supported.
> > > Rule instances may be reused across
> > > properties if desired.
> > > </description>
> > > <entry key=3D"name.lastName">
> > > <value><bean
> > > class=3D"org.springframework.validation.rules.Required"/></value>
> > > </entry>
> > > <entry key=3D"favoriteToy">
> > > <value>
> > > <set>
> > > <bean
> > > class=3D"org.springframework.validation.rules.Required"/>
> > > <bean
> > > class=3D"org.springframework.validation.rules.MaxLength">
> > > =09
> > > <constructor-arg>25</constructor-arg>
> > >
> > > </bean>
> > > </set>
> > > </value>
> > > </entry>
> > > </map>
> > > </bean>
> > >
> > > Java
> > >
> > >         BeanValidatorBuilder builder =3D new =
> > > BeanValidatorBuilder(Pet.class);
> > >
> > >         builder.setPropertyValidator("name.lastName", new Required());

> > >
> > >         Set toyRules =3D new HashSet();
> > >         toyRules.add(new Required());
> > >         toyRules.add(new MaxLength(255));
> > >         builder.setPropertyValidator("favoriteToy", toyRules);
> > >
> > > Keith
> >
> > sam
> > http://www.magpiebrain.com/
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] commons attributes questions

[Cameron B. <ca...@da...>]

Yeah, I am using commons attributes for transaction declaration.

We have a system where we use a method name match transaction attribute
source as the fallback, and allow declarations on at the method level to
override these defaults, since most of the time the defaults work perfectly,
and these defaults are defined per application anyway.


Something like this in applicationContext.xml

<bean id="commonsAttributes"
class="org.springframework.metadata.commons.CommonsAttributes"/>

<!-- transaction attribute source to provide a method name based map -->
<bean id="attributesMatchMethodNamePattern"
class="org.springframework.transaction.interceptor.NameMatchTransactionAttri
buteSource">
	<property name="properties">
		<props>
			<!-- read only methods -->
			<prop
key="list*">PROPAGATION_REQUIRED,readOnly</prop>
			<prop
key="find*">PROPAGATION_REQUIRED,readOnly</prop>
			<prop
key="get*">PROPAGATION_REQUIRED,readOnly</prop>
			<prop
key="load*">PROPAGATION_REQUIRED,readOnly</prop>
			<!-- the default is transactional (least specific,
match everything) -->
			<prop key="*">PROPAGATION_REQUIRED</prop>
		</props>
	</property>
</bean>

<bean id="attributesAttributeSource"
class="org.springframework.transaction.interceptor.AttributesTransactionAttr
ibuteSource">
	<constructor-arg><ref bean="commonsAttributes"/></constructor-arg>
</bean>


<bean id="multiAttributeSource"
class="transaction.interceptor.ListTransactionAttributeSource">
	<property name="attributeSources">
		<list>
			<ref bean="attributesAttributeSource"/>
			<ref bean="attributesMatchMethodNamePattern"/>
		</list>
	</property>
</bean>

> -----Original Message-----
> From: spr...@li... 
> [mailto:spr...@li...]
>  On Behalf Of Rod Johnson
> Sent: Thursday, 11 March 2004 10:00 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] commons attributes questions
> 
> > I'm glad to learn we can shorten the attribute declarations 
> by leaving 
> > off the package.  Very nice!
> 
> That was actually my suggestion, based on Mark's attrib4j. I 
> also requested the support for JavaBean properties, to make 
> it easier to use with Spring.
> 
> Is anyone using Commons Attributes for declarative tx mgt (as 
> in jPetStore /attributes)?
> 
> Or the commons attributes handler mapping?
> 
> Regards,
> Rod
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials Free 
> Linux tutorial presented by Daniel Robbins, President and CEO 
> of GenToo technologies. Learn everything from fundamentals to 
> system 
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 

Re: [Springframework-developer] commons attributes questions

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

> Are there some examples of the handler/controller attributes?

Look under metadata in the reference manual. There isn't (yet) an example in
the sample apps.