springframework-developer — Spring Framework developers list

Re: [Springframework-developer] webflow: validator invocation strategy

[Erwin V. <erw...@er...>]

I would say: just subclass FormAction and redefine either 
validate(RequestContext, Object, Errors) or invokeValidatorMethod(String, 
Object, Errors). Typically you could do that in a custom FormAction base 
class that you use for all form actions in your project.

Erwin Vervaet
----- Original Message ----- 
From: "Steven Devijver" <ste...@gm...>
To: <spr...@li...>
Sent: Thursday, April 21, 2005 9:39 AM
Subject: [Springframework-developer] webflow: validator invocation strategy


Hi guys,

You recently extended validator invocation functionality in Web Flow
by calling a specific method on a validator instance. I propose to
make this behavior more generic. While I think calling a specific
method on the validator is a great way to do validation across
multiple pages there's a comparable strategy I would like to see
implemented.

I would like to call a collection of validators linked to a specific
string token in a map. The string token would be the equivalent of a
method name and would be defined in the flow config.

In order to implement this I propose to call specific validator
invocations through an interface that would allow different strategies
to be implemented.

Kind regards

Steven

-- 
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart


-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Christoph Miksovic/Switzerland/IBM is out of the office.

[Christoph M. <chr...@ch...>]

I will be out of the office starting  12.05.2005 and will not return until
19.05.2005.

RE: [Springframework-developer] Declarative Validation Framework in Spring's Future?

[Oliver H. <Ol...@ou...>]

> Thanks for the pointer Oliver. I couldn't find the=20
> declarative part of Keith rules system in the sandbox but I=20
> guess it's a work in progress.

The Rules class is where you declare your validation. eg.

	new Rules(Owner.class) {
            protected void initRules() {
                add("firstName", getNameValueConstraint());
                add("lastName", getNameValueConstraint());
                add(not(eqProperty("firstName", "lastName")));
                add("address", required());
            }

            private Constraint getNameValueConstraint() {
                return all(new Constraint[] { required(), maxLength(25),
regexp("[a-zA-Z]*", "alphabetic") });
            }

        };

This code is out the pet clinic sample app for SpringRich.

Ollie

[Springframework-developer] spring Build Failed

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050513001645

Re: [Springframework-developer] Portlet MVC Status

[Juergen H. <ju...@in...>]

Quite accurate, that assumption :-)

My single most important concern is 1.2 final - has been for the past few
weeks. There's a whole load of new stuff in 1.2, and it shows in terms of
refinement and maintenance effort. The TopLink support alone took far more
time than expected...

Anyway, the Portlet support is a key feature for Spring 1.3, alongside
Spring Web Flow. I intend to kick that work off right after 1.2 final, so
please stay tuned :-)

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Tim Kettering
Sent: Thursday, May 12, 2005 5:37 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Portlet MVC Status



We too have an interest in the portlet integration with Spring, and this
state of limbo is starting to get a bit distressing.  I suspect that
Juergen's simply trying to get 1.2 out the door - and that once he does so
tomorrow, there will be more progress on this end when 1.3 dev begins in
earnest - at least I hope so.  I don't profess to know what exactly is on
the Spring developer's minds right now.  :)

-tim


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
John Lewis
Sent: Wednesday, May 11, 2005 7:55 PM
To: spr...@li...
Subject: [Springframework-developer] Portlet MVC Status

It's been over a month since this discussion and there is still no
progress on merging together the contributions to the Portlet MVC
framework.  Several of us are working with this framework on critical
projects and would really like to start moving it forward in a reliable
direction.

Would it be better for us to start a separate sourceforge or java.net
project for this until we can work on merging back into Spring proper,
or is there some light at the end of this tunnel?


> Juergen Hoeller wrote:
>
>> That sounds like a good plan to me! It would be great to get this going
>> ASAP. After all, our timeplan for Spring 1.3 is pretty aggressive, so
>> waiting till after 1.2 final might not leave enough time.
>>
>> Bill, Dmitriy, anyone volunteering to manage the sandbox code in the
>> meantime? :-) This would have to be someone with commit rights, after
>> all,
>> and ideally someone already using the Portlet code.
>
>> First step would be to merge all existing contributions in. Let's assume
>> that the Portlet code will become part of Spring 1.3 proper (which is
>> likely), and continue to work on it in the sandbox.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On Behalf
>> Of Rainer Schmitz
>> Sent: Wednesday, March 30, 2005 11:53 AM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] Re: Portlet Form Controllers
>>
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> While the "official" work on the Portlet support are postponed to Spring
>> 1.3 I still would like to have a place for discussions and code
>> contributions. At this time the discussion is spread across this list,
>> the forum, confluence, and JIRA, which makes it hard to follow.
>>
>> As for discussions, I would propose to stick to this list - we *are*
>> talking about Spring development, and this way the experienced Spring
>> developers may take the opportunity to participate.
>>
>> As for code contributios: during the past couple of month several people
>> (William, Nick, John, and me) have contributed some code, but after each
>> contribution there was a big gap. One reason might be that it's very
>> inconvenient to get the up-to-date version of the code (none of the
>> changes made it into CVS; you have to fetch the sandbox version and copy
>> the content of several zip files from confluence). Without a proper code
>> management facility it's pointless to add more contributions.
>>
>> I'm undecided wether portlet support should be part of main Spring or a
>> sub project, but for the time being it would really help if the portlet
>> code would be located at a place where all interested people could find
>> the up-to-date version and contribute enhancements. When the official
>> work in the Spring 1.3 context begins, this code could be an
>> implementation base for any portlet code handled in the traditional way.
>>
>> What do you think?
>>
>> Rainer
>>
>>
>>
>> Juergen Hoeller schrieb:
>>
>>> John,
>>>
>>> Sorry for the late reply. Thanks for volunteering! :-)
>>>
>>> Let's continue to proceed in the Portlet area once Spring 1.2 is
>>> out. Both
>>> Spring Web Flows and the Portlet support are currently planned to be
>>> cornerstones of Spring 1.3.
>>>
>>> Regarding commit rights, let's discuss this once 1.2 is out too. We're
>>> willing to extend the developer team, but there's a couple of things
>>> to be
>>> clarified (CLA etc).
>>>
>>> In the meantime, feel free to create a JIRA issue for your
>>> enhancements!
>>
>>
>> I'm
>>
>>> sure that Dmitriy, Bill and co will be happy to have an early look at
>>
>>
>> this.
>>
>>> Juergen
>>>
>>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.2.2 (MingW32)
>> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>>
>> iD8DBQFCSnb7w+xsU7A7UOgRAo39AJ9LlKn1KvEOFzItXO83+oUoUhvMHgCfWoVy
>> rv556WE9CYsBzgbrTtkRqLU=
>> =qCQl
>> -----END PGP SIGNATURE-----
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Portlet MVC Status

[Tim K. <tim...@vi...>]

We too have an interest in the portlet integration with Spring, and this
state of limbo is starting to get a bit distressing.  I suspect that
Juergen's simply trying to get 1.2 out the door - and that once he does so
tomorrow, there will be more progress on this end when 1.3 dev begins in
earnest - at least I hope so.  I don't profess to know what exactly is on
the Spring developer's minds right now.  :)

-tim


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
John Lewis
Sent: Wednesday, May 11, 2005 7:55 PM
To: spr...@li...
Subject: [Springframework-developer] Portlet MVC Status

It's been over a month since this discussion and there is still no 
progress on merging together the contributions to the Portlet MVC 
framework.  Several of us are working with this framework on critical 
projects and would really like to start moving it forward in a reliable 
direction.

Would it be better for us to start a separate sourceforge or java.net 
project for this until we can work on merging back into Spring proper, 
or is there some light at the end of this tunnel?


> Juergen Hoeller wrote:
>
>> That sounds like a good plan to me! It would be great to get this going
>> ASAP. After all, our timeplan for Spring 1.3 is pretty aggressive, so
>> waiting till after 1.2 final might not leave enough time.
>>
>> Bill, Dmitriy, anyone volunteering to manage the sandbox code in the
>> meantime? :-) This would have to be someone with commit rights, after 
>> all,
>> and ideally someone already using the Portlet code.
>
>> First step would be to merge all existing contributions in. Let's assume
>> that the Portlet code will become part of Spring 1.3 proper (which is
>> likely), and continue to work on it in the sandbox.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On Behalf
>> Of Rainer Schmitz
>> Sent: Wednesday, March 30, 2005 11:53 AM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] Re: Portlet Form Controllers
>>
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> While the "official" work on the Portlet support are postponed to Spring
>> 1.3 I still would like to have a place for discussions and code
>> contributions. At this time the discussion is spread across this list,
>> the forum, confluence, and JIRA, which makes it hard to follow.
>>
>> As for discussions, I would propose to stick to this list - we *are*
>> talking about Spring development, and this way the experienced Spring
>> developers may take the opportunity to participate.
>>
>> As for code contributios: during the past couple of month several people
>> (William, Nick, John, and me) have contributed some code, but after each
>> contribution there was a big gap. One reason might be that it's very
>> inconvenient to get the up-to-date version of the code (none of the
>> changes made it into CVS; you have to fetch the sandbox version and copy
>> the content of several zip files from confluence). Without a proper code
>> management facility it's pointless to add more contributions.
>>
>> I'm undecided wether portlet support should be part of main Spring or a
>> sub project, but for the time being it would really help if the portlet
>> code would be located at a place where all interested people could find
>> the up-to-date version and contribute enhancements. When the official
>> work in the Spring 1.3 context begins, this code could be an
>> implementation base for any portlet code handled in the traditional way.
>>
>> What do you think?
>>
>> Rainer
>>
>>
>>
>> Juergen Hoeller schrieb:
>>
>>> John,
>>>
>>> Sorry for the late reply. Thanks for volunteering! :-)
>>>
>>> Let's continue to proceed in the Portlet area once Spring 1.2 is 
>>> out. Both
>>> Spring Web Flows and the Portlet support are currently planned to be
>>> cornerstones of Spring 1.3.
>>>
>>> Regarding commit rights, let's discuss this once 1.2 is out too. We're
>>> willing to extend the developer team, but there's a couple of things 
>>> to be
>>> clarified (CLA etc).
>>>
>>> In the meantime, feel free to create a JIRA issue for your 
>>> enhancements!
>>
>>
>> I'm
>>
>>> sure that Dmitriy, Bill and co will be happy to have an early look at
>>
>>
>> this.
>>
>>> Juergen
>>>
>>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.2.2 (MingW32)
>> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>>
>> iD8DBQFCSnb7w+xsU7A7UOgRAo39AJ9LlKn1KvEOFzItXO83+oUoUhvMHgCfWoVy
>> rv556WE9CYsBzgbrTtkRqLU=
>> =qCQl
>> -----END PGP SIGNATURE-----
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring 1.2 final completed: TopLink, Hibernate3, JDO2

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

Juergen Hoeller wrote:

>Hi everybody,
>
>I've just finished the last bunch of data access refinements I wanted to get
>into Spring 1.2 final:
>
>...
>
>* I've refined the semantics of the "allowCreate" flag for all of our ORM
>templates: This only applies to the creation of non-transactional resources
>now. If "allowCreate" is "false", on-the-fly synchronization of a resource
>with the current transaction is still allowed. This is in line with the
>behavior of TopLink's "getActiveSession" and Hibernate3's
>"getCurrentSession", and IMO generally reasonable: eager vs lazy transaction
>synchronization should be fully transparent to the user; usually, only the
>creation of a non-transactional resource is (potentially) undesirable.
>
>  
>
I like this. I had generally recommended to people that they set the 
flag to false, and use HibernateInterceptor, when working with 
JTATransactionmanager, so that they would catch cases where they 
acciddentally not wrapping transactionally, and creating 
non-transacitonal sessions. Now this change allows JTA usage with the 
flag still set to false, but with no HibernateInterceptor needed any 
longer, and people can rely on the fact that a  lazily created Session 
will still join the transaction, but there will still be a failure when 
there is no transaction...

[Springframework-developer] Spring 1.2 final completed: TopLink, Hibernate3, JDO2

[Juergen H. <ju...@in...>]

Hi everybody,

I've just finished the last bunch of data access refinements I wanted to get
into Spring 1.2 final:

* The TopLink support is able to expose a transaction-aware TopLink Session
as bean reference, to be passed to plain TopLink DAOs which use TopLink API
only (without Spring dependencies in DAO code). Such a Session exposes the
Spring-managed transactional Session on "Session.getActiveSession" and
"Session.getActiveUnitOfWork", analogous to TopLink's behavior in a JTA
environment. I've confirmed that this works on both TopLink 9.0.4 and
10.1.3.

* The Hibernate3 support exposes a SessionFactory proxy that returns the
Spring-managed transactional Session on Hibernate 3.0.1's
"SessionFactory.getCurrentSession", analogous to Hibernate's behavior in a
JTA environment. This allows plain Hibernate DAOs to receive a
SessionFactory reference and participate in Spring-managed transactions with
Hibernate API only, being able to seamlessly participate in plain JTA
transactions as well.

* Our LocalSessionFactoryBean for Hibernate3 sets Hibernate 3.0.3's
Connection release mode to "after_transaction" or "after_statement",
depending on the transaction awareness of the underlying DataSource. The
resulting behavior is much nicer than before: using a transaction-aware
DataSource for the Hibernate SessionFactory is not an issue anymore, not
even with Open Session In View, removing a configuration headache when you
need stuff like transaction timeouts for inserts/updates. Issues with
misbehaving JTA implementations can be solved with this as well.

* The JDO support includes a TransactionAwarePersistenceManagerFactoryProxy,
exposing a JDO PersistenceManagerFactory reference that returns the
Spring-managed transactional PersistenceManager on "getPersistenceManager",
and suppresses "PersistenceManager.close" accordingly. This allows plain JDO
DAOs to receive a PersistenceManagerFactory reference and participate in
Spring-managed transactions with JDO API only.

* Spring's JDO support fully covers JDO 2.0 now, both in terms of
JdoTemplate operations (getObjectById behavior, detach, reattach,
findByNamedQuery, find with single string query, etc) and in terms of the
DefaultJdoDialect implementation (flush, JDBC Connection access). I have
tested this against JPOX 1.1.0 beta 3 as well as against JPOX 1.0, for
compatibility with both JDO 2.0 and 1.0. The JDO2 API jar that we compile
against is the pre-release jar taken from JPOX.

* I've refined the semantics of the "allowCreate" flag for all of our ORM
templates: This only applies to the creation of non-transactional resources
now. If "allowCreate" is "false", on-the-fly synchronization of a resource
with the current transaction is still allowed. This is in line with the
behavior of TopLink's "getActiveSession" and Hibernate3's
"getCurrentSession", and IMO generally reasonable: eager vs lazy transaction
synchronization should be fully transparent to the user; usually, only the
creation of a non-transactional resource is (potentially) undesirable.

* I've also deprecated all our "closeXxxIfNecessary" methods in favor of new
"releaseXxx" methods. "get"/"release" pairs are much nicer than
"get"/"closeIfNecessary", in particular as the release methods do not just
perform close-if-necessary anymore: they also manage reference counters etc.
"release" is the proper term for what they do these days, IMO (and is also
the term used by TopLink, BTW).

I'm going into sample app test mode now, and intend to go forward with the
actual Spring 1.2 final release if there aren't any objections. So if you
have any feedback on those recent changes, please voice it at your earliest
convenience :-) The actual release won't happen before tonight, so there's
still half a day to go.

Juergen

Re: [Springframework-developer] JIRA problems

[Mike Cannon-B. <mca...@gm...>]

Hey guys,

Sorry - been out. Is this still an issue? I know they were doing some
work on the box in preparation for the 3.2 release and reindexed the
Spring instance in the process. It should have only taken an hour or
two at max though.

If still an issue, please let me know.

Cheers,
Mike

PS Anyone on the Spring team can email jir...@at... to
get support for your instance, your names are all well known to the
JIRA guys (even though they don't use Spring - yet ... :))

On 5/8/05, Mark St Godard <stg...@ca...> wrote:
>=20
>=20
> Rather "cannot" view issues, roadmap, etc.
> Type-o
> Cheers,
> Mark
>=20
>              Mark St
>              Godard/CanWest/IB
>              M@IBMCA                                                    T=
o
>              Sent by:                  spr...@li...=
u
>              springframework-d         rceforge.net
>              eveloper-admin@li                                          c=
c
>              sts.sourceforge.n
>              et                                                    Subjec=
t
>                                        Re: [Springframework-developer]
>                                        JIRA problems
>              05/08/2005 08:28
>              PM
>=20
>              Please respond to
>              springframework-d
>                  eveloper
>=20
> Ditto,   I have been having problems too..
> I can get main Spring  JIRA page, just can view issues, roadmap, etc.
>=20
> Cheers,
> Mark
>=20
>              "Juergen Hoeller"
>              <juergen@interfac
>              e21.com>                                                   T=
o
>              Sent by:                  <springframework-developer@lists.s=
o
>              springframework-d         urceforge.net>
>              eveloper-admin@li                                          c=
c
>              sts.sourceforge.n
>              et                                                    Subjec=
t
>                                        [Springframework-developer] JIRA
>                                        problems
>              05/08/2005 04:10
>              PM
>=20
>              Please respond to
>              springframework-d
>                  eveloper
>=20
> I can hardly access our JIRA today... I keep getting a mixture of proxy
> errors and JIRA system errors. Is it just me, or do we have a general iss=
ue
> there?
>=20
> A bit of a pain, given that Spring 1.2 final is supposed to be released a=
ny
> day now. I NEED JIRA ;-)
>=20
> Juergen
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, =
4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=3D20
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, =
4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=3D20
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, =
4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=3D20
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20


--=20
ATLASSIAN - http://www.atlassian.com

Re: [Springframework-developer] Declarative Validation Framework in Spring's Future?

[Steven D. <ste...@gm...>]

Thanks for the pointer Oliver. I couldn't find the declarative part of
Keith rules system in the sandbox but I guess it's a work in progress.
For me the declarative part is the most important part of a validation
tool. How the back-end is implemented is of minor importance to me as
long as it does restrict the validation functionality. The predicates
offered by commons collections are a perfect fit for me. It allows the
valang parser to return a common interface that's reusable elsewhere.

Based on Keith's wish list I feel valang currently fulfills them all
except the second to last:

    *  We want a framework that focuses on validating business
objects, not one that is coupled with the presentation tier or any
view, form, or controller technology.
        Valang does this but implementing Spring's Validator interface.

    * We want a framework that makes it easy to define new rules, and
makes rules top-level-objects that can be reused in other contexts
(and are not tightly coupled with the framework.)
        Valang uses the Predicate interface from commons collections
and as such creates rules that are reusable elsewhere.

    * We want a framework which supports expressions using relational
operators (<,>,<=3D,>=3D,=3D=3D,!), logical operators (and/or), and
conditionals to allow for the creation of semantic business rules in
addition to simple syntax checks.
        The valang parser offers a range of language constructs that
go beyond these requirements and that will be extended over time.

    * We want a framework that is capable of reporting rich,
internationalized validation results on rule evaluation.
       Valang offers i18n support, thanks to feedback of C=E8sar Ordi=F1ana=
.

    * We want a framework that is capable of generating typing hints
and other visual indicators for rules that constrain bean property
values to enhance an application's usability and overall user
experience.
         I'm not sure what the requirements are but I'm sire this can be ad=
ded.

    * And for the Swing crowd, we want something that works just as
well in a web-app environment as it does in a rich-client environment.
        For me this is a duplicate of the first requirement.

Regarding the design goals I think valang also scores a number of hits:

    *  The design should make it extremely easy to define new rules
and integrate those rules into the rest of the framework.
        I'm not sure if "rule" means an actual rule (ex. "age >=3D 18")
or an operator test. Adding rules to valang is extremely simple. The
way valang handles operator test is currenlty sub-optimal when it
comes to extending but this can be improved.

          o To facilitate this, the design should decouple rule
evaluation from results reporting.
               Valang does this.

    * The design should cleary decouple the validation of values from
how those values are retrieved. This allows the value checks to be
more easily reused.
         Valang retrieves bean values in one place. This mechanism is
currently not pluggable but this can also be improved, for example by
means of the visitor pattern.

          o For example, the act of retrieving a bean property value
should be decoupled from taking that value and testing it against one
or more constraints. The constraints should have no knowledge of how
the value was obtained.
            Valang does this.

    * The design should provide pluggable rules sources. Initially we
plan to support programatically defined sources and commons-attributes
sources, but others such as xml-based or scripting based should be
possible.
        Although the factory bean currently does not support this you
could for example provide your own predicate instance instead of
having them created by valang parser.

    * The design should leverage Spring's existing infrastructure
where appropriate and should in general not re-invent the wheel.
         I think valang currenlty does this but I'm sure there's room
for improvement.

    * The framework should provide a library of out-of-the-box rules
and regularly integrate back community contributions over time.
        Valang does this I think. I've incorporate all the feedback I
received thus far. Valang is currently scheduled for release with
spring modules 0.3.


In general valang isn't final yet. I'm happy to discuss with anyone
how valang can be improved. I'm also open to merge valang with other
initiatives for the sake of creating the most usable and flexible
tool. There currently aren't a lot of solutions available in
declarative validation land and valang is currently nothing more than
a attempt to provide a solution.

I thinks its strongest point is the parser that can be an alternative
to programmatic declaration. I keep extending the parser's
functionality and while we keep the discussion of how declarative
validation should be done alive we will have a strong evaluation
language available if and when we will have an outcome.


Steven



On 5/12/05, Oliver Hutchison <Ol...@ou...> wrote:
> Steven,
>=20
> > I didn't know Keith had plans for a declarative validation solution.
> > I'm looking forward to hear his ideas on the subject.
>=20
> Keith's already started work on his declarative validation framework!
> The code is in the sandbox's org.springframework.rules package. There's
> also a page about it in the wiki:
> http://opensource.atlassian.com/confluence/spring/display/DOC/Declarativ
> e+Validation?focusedCommentId=3D132
>=20
> From my (very brief) look at what you've done with Valang it appears
> there is a strong synergy between the 2 projects. Your functions and
> predicates packages have a lot of similarities with Keith's closure and
> constraint packages. I suspect that it wouldn't be hard to reimplement
> your Valang parser so that it generated Keith's Rules.
>=20
> Ollie
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_ids93&alloc_id=16281&opclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20


--=20
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart

Re: [Springframework-developer] Re: OpenSessionInView and portlet support

[J.Enrique Ruiz-V. <er...@di...>]

+1 for Portlet MVC integration

> I agree that a refactoring of the code is the best permanent solution. 
> Hopefully we can take this track when we really start working on 
> getting the Portlet MVC framework integrated into Spring.
>
> Rob Butler wrote:
>
>> Why not refactor the OpenSessionInViewInterceptor  to
>> a new class called CommonOpenSessionInViewInterceptor
>> and have it operate on a set of new interfaces called
>> CommonRequest and CommonResponse.
>>
>> Then have two separate implementations.  One is called
>> OpenSessionInViewInterceptor (to replace the original
>> and remain backward compatible with existing code). The other is 
>> PortletOpenSessionInViewInterceptor. These classes can then wrap (not 
>> extend) the
>> CommonOpenSessionInViewInterceptor ala the adapter
>> pattern.  These classes each have inner classes that
>> implement the web/portlet version of CommonRequest &
>> CommonResponse, and pass these to the
>> CommonOpenSessionInViewInterceptor.
>>
>> End result, no code duplication, Spring web MVC is not
>> tied to Portlet MVC, and you no longer have to hope
>> that PortletRequest is really a HttpServletRequest.
>>
>> Just an idea.
>> Rob
>

-- 
J.Enrique Ruiz Valenciano
CIO, DiSiD S.L.L. (http://www.disid.com)
Email: er...@di...

Re: [Springframework-developer] jstl 1.1

[Juergen H. <ju...@in...>]

Well, there simply is no need to. We only use the Jakarta JSTL for two
things: the ExpressionEvaluationManager as fallback for JSTL EL parsing on
JSP <2.0, and for some of our sample applications (which are all Servlet
2.3/JSP 1.2). So Jakarta JSTL 1.0 is perfectly fine and even required for
our needs, which is we ship that version.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Darrell Kundel
Sent: Thursday, May 12, 2005 8:08 AM
To: spr...@li...
Subject: [Springframework-developer] jstl 1.1


Hi Everyone,

Is there any reason why Jakarta jstl 1.1 isn't included in the dependent
libraries of Spring?

Darrell



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_ids93&alloc_id281&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Attempt to mirror CVS (cvs.sourceforge.net) using SVK

[Chris T. <chr...@gm...>]

Hi,

I am attempting to utilize a version control system called SVK with
the spring project.  SVK is a decentralized version control that uses
the subversion libraries.  It has the ability mirror a remote CVS
repository using VCP.

I am trying mirror Spring's CVS repository with it.  On the first try,
the mirroring chugs along for several hours, until it hits a commit
comment it cannot decode properly.  Upon subsequent tries, the
mirroring does not take as long, but it always fails at the same point
with a decoding error.

I spoke with the SVK developer, he said the error is occuring when
converting one of the commit comments to UTF-8.  The problem is the
SVK error message is vague, so I am unable to track down the offending
commit comment.

Right now I am using UTF-8 encoding.  Is there any special encoding
that may have been used for commit comments?

Has anyone successfully used SVK to mirror Spring's CVS repository?=20
If so, did you have to do anything special?

Thanks,
Chris Tilden

[Springframework-developer] Re: OpenSessionInView and portlet support

[John L. <jl...@ar...>]

I agree that a refactoring of the code is the best permanent solution. 
Hopefully we can take this track when we really start working on getting 
the Portlet MVC framework integrated into Spring.

Rob Butler wrote:
> Why not refactor the OpenSessionInViewInterceptor  to
> a new class called CommonOpenSessionInViewInterceptor
> and have it operate on a set of new interfaces called
> CommonRequest and CommonResponse.
> 
> Then have two separate implementations.  One is called
> OpenSessionInViewInterceptor (to replace the original
> and remain backward compatible with existing code). 
> The other is PortletOpenSessionInViewInterceptor. 
> These classes can then wrap (not extend) the
> CommonOpenSessionInViewInterceptor ala the adapter
> pattern.  These classes each have inner classes that
> implement the web/portlet version of CommonRequest &
> CommonResponse, and pass these to the
> CommonOpenSessionInViewInterceptor.
> 
> End result, no code duplication, Spring web MVC is not
> tied to Portlet MVC, and you no longer have to hope
> that PortletRequest is really a HttpServletRequest.
> 
> Just an idea.
> Rob
> 
> 
> --- John Lewis <jl...@ar...> wrote:
> 
> 
>>Hi.  I just ran across this thread and thought I
>>would mention our 
>>current solution to this issue.
>>
>>As discussed, filters do not apply to portlets, nor
>>should they since 
>>they are for filtering servlet requests and portlets
>>are really a 
>>different animal.  However, the use of Spring
>>interceptors works 
>>perfectly for portlets and is the right way to go.
>>
>>For now, we have taken advantage of a fact that I
>>believe is true for 
>>most/all JSR-168 portal platforms: the
>>PortletRequest and 
>>PortletResponse objects are also the
>>HttpServletRequest and 
>>HttpServletResponse objects.  Because this is true,
>>we are just 
>>delegating to the existing
>>OpenSessionInViewInterceptor class.  This is 
>>not required by the JSR-168 spec and so is not
>>guaranteed to work, but 
>>it has been true on all the platforms I have checked
>>so far.
>>
>>Below are the contents of the class we are currently
>>using.  I hope you 
>>find this helpful.  I'd love to hear feedback from
>>others on this.  Has 
>>anyone been using a portal platform where this will
>>not work?
>>
>>I'd like to include this class in the Portlet MVC
>>framework in the 
>>sandbox once we can get some motion going with that
>>again.
>>
>>-- John Lewis
>>
>>
>>
>>/*
>> * Copyright 2002-2004 the original author or
>>authors.
>> *
>> * Licensed under the Apache License, Version 2.0
>>(the "License");
>> * you may not use this file except in compliance
>>with the License.
>> * You may obtain a copy of the License at
>> *
>> *      http://www.apache.org/licenses/LICENSE-2.0
>> *
>> * Unless required by applicable law or agreed to in
>>writing, software
>> * distributed under the License is distributed on
>>an "AS IS" BASIS,
>> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
>>either express or implied.
>> * See the License for the specific language
>>governing permissions and
>> * limitations under the License.
>> */
>>
>>package
>>org.springframework.web.portlet.support.hibernate;
>>
>>import javax.portlet.PortletRequest;
>>import javax.portlet.PortletResponse;
>>import javax.portlet.RenderRequest;
>>import javax.portlet.RenderResponse;
>>import javax.servlet.http.HttpServletRequest;
>>import javax.servlet.http.HttpServletResponse;
>>
>>import
>>
> 
> org.springframework.web.portlet.PortletControllerInterceptor;
> 
>>import
>>
> 
> org.springframework.web.portlet.support.PortletController;
> 
>>import org.springframework.web.servlet.ModelAndView;
>>
>>/**
>> * <p>PortletControllerInteceptor that provides
>>access to an open
>> * Hibernate session in the view.</p>
>> *
>> * <p>This implementation delgates to
>> * 
>>
> 
> <code>org.springframework.orm.hibernate.support.OpenSessionInViewInterceptor</code>,
> 
>> * but this only works if the
>><code>PortletRequest</code> and 
>><code>PortletReponse</code> objects
>> * involved are also instances of
>><code>HttpServletRequest</code> and 
>><code>HttpServletReponse</code>.
>> * While most portal providers do implement their
>>classes this way, it 
>>is not
>> * part of the JSR-168 spec and is not guaranteed to
>>work.  Be sure to test
>> * this with any target portal platforms before
>>comitting to usage of this
>> * class.</p>
>> *
>> * <p>TODO: Reimplement this class as a standalone
>>Interceptor without 
>>the above limitation.</p>
>> *
>> * @author John Lewis
>> * @see 
>>
> 
> org.springframework.orm.hibernate.support.OpenSessionInViewInterceptor
> 
>> */
>>public class OpenSessionInViewInterceptor extends
>>        
>>
> 
> org.springframework.orm.hibernate.support.OpenSessionInViewInterceptor
> 
>>        implements PortletControllerInterceptor {
>>
>>    public boolean preController(PortletRequest
>>request, PortletResponse 
>>response,
>>            PortletController handler) throws
>>Exception {
>>        if (request instanceof HttpServletRequest &&
>>                response instanceof
>>HttpServletResponse)
>>            return
>>super.preHandle((HttpServletRequest)request, 
>>(HttpServletResponse)response,
>>                    (Object)handler);
>>        return false;
>>    }
>>
>>    public void postController(RenderRequest
>>request, RenderResponse 
>>response,
>>            PortletController handler, ModelAndView
>>modelAndView) throws 
>>Exception {
>>        if (request instanceof HttpServletRequest &&
>>                response instanceof
>>HttpServletResponse)
>>           
>>super.postHandle((HttpServletRequest)request, 
>>(HttpServletResponse)response,
>>                    (Object)handler, modelAndView);
>>    }
>>
>>    public void afterCompletion(PortletRequest
>>request, PortletResponse 
>>response,
>>            PortletController handler, Exception ex)
>>throws Exception {
>>        if (request instanceof HttpServletRequest &&
>>                response instanceof
>>HttpServletResponse)
>>           
>>super.afterCompletion((HttpServletRequest)request, 
>>(HttpServletResponse)response,
>>                    (Object)handler, ex);
>>    }
>>
>>}
>>
>>
>>
>>
>>
>>
>>
>>J. Enrique Ruiz wrote:
>>
>>
>>>Hi,
>>>
>>>A Portlet is not a Servlet, a set of portlets are
>>
>>invoked directly by 
>>
>>>the portlet-container in one client request.
>>>
>>>The portlet spec says: "If the client request is
>>
>>triggered by an 
>>
>>>action URL, the portal/portlet-container must
>>
>>first trigger the action 
>>
>>>request by invoking the processAction method of
>>
>>the targeted portlet. 
>>
>>>The portal/portlet-container must wait until the
>>
>>action request 
>>
>>>finishes. Then, the portal/portlet-container must
>>
>>trigger the render 
>>
>>>request by invoking the render method for all the
>>
>>portlets in the 
>>
>>>portal page with the possible exception of
>>
>>portlets for which their 
>>
>>>content is being cached. The render requests may
>>
>>be executed 
>>
>>>sequentially or in parallel without any guaranteed
>>
>>order."
>>
>>>Note that 'the render request may be executed IN
>>
>>PARALLEL', as I 
>>
>>>understand it, each render request could be
>>
>>executed on different 
>>
>>>threads. I think this feature advises against the
>>
>>use of 
>>
>>>OpenSessionInViewFilter class with portlets.
>>>
>>>
>>>>Well, if OpenSessionInViewFilter doesn't kick in
>>
>>for portlets, no other
>>
>>>>filter will kick in with portlets either. Isn't
>>
>>there maybe some general
>>
>>>>issue hiding there?
>>>>
>>>>Of course we can provide an
>>
>>OpenSessionInViewInterceptor for 
>>
>>>>portlets, but
>>>>I'm not sure whether that's actually a good fit
>>
>>there. The Portlet 
>>
>>>>request
>>>>flow with separate handle and render callbacks
>>
>>makes this less 
>>
>>>>compelling.
>>>>
>>>>What we certainly can't do is let the existing 
>>>>OpenSessionInViewInterceptor
>>>>implement some PortletControllerInterceptor
>>
>>interface. That would force
>>
>>>>every Servlet user to have the portlet.jar on the
>>
>>classpath.
>>
>>>>Juergen
>>>>
>>>>
>>>>-----Original Message-----
>>>>From:
>>
> spr...@li...
> 
> [mailto:spr...@li...]On
> 
>>Behalf
>>
>>>>Of Erwin Vervaet
>>>>Sent: Tuesday, April 19, 2005 9:26 PM
>>>>To:
>>
>>spr...@li...
>>
>>>>Subject: [Springframework-developer]
>>
>>OpenSessionInView and portlet
>>
>>>>support
>>>>
>>>>
>>>>Apparently the existing OSIV filter does not work
>>
>>with portlets:
>>
>>>>
> http://forum.springframework.org/viewtopic.php?t=4907
> 
>>>>I guess we should tackle this issue when doing
>>
>>the Portlet support 
>>
>>>>for 1.3.
>>>>There is no PortletMVC category in JIRA so I'm
>>
>>not sure where to file 
>>
>>>>it...
>>>>Any input from the Porlet people?
>>>>
>>>>Erwin Vervaet
>>>>erw...@er...
>>>>
>>>>
>>>>
>>>>
>>
> -------------------------------------------------------
> 
>>>>This SF.Net email is sponsored by: New Crystal
>>
>>Reports XI.
>>
>>>>Version 11 adds new functionality designed to
>>
>>reduce time involved in
>>
>>>>creating, integrating, and deploying reporting
>>
>>solutions. Free 
>>
>>>>runtime info,
>>>>new features, or free trial, at: 
>>>>http://www.businessobjects.com/devxi/728
>>>>_______________________________________________
>>>>Springframework-developer mailing list
>>>>Spr...@li...
>>>>
>>
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
>>>>
>>>>
>>>>
> -------------------------------------------------------
> 
>>>>This SF.Net email is sponsored by: New Crystal
>>
>>Reports XI.
>>
>>>>Version 11 adds new functionality designed to
>>
>>reduce time involved in
>>
>>>>creating, integrating, and deploying reporting
>>
>>solutions. Free 
>>
>>>>runtime info,
>>>>new features, or free trial, at: 
>>>>http://www.businessobjects.com/devxi/728
>>>>_______________________________________________
>>>>Springframework-developer mailing list
>>>>Spr...@li...
>>>>
>>
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
>>>> 
>>>>
>>>
>>>
>>
>>
>>
> -------------------------------------------------------
> 
>>This SF.Net email is sponsored by Oracle Space
>>Sweepstakes
>>Want to be the first software developer in space?
>>Enter now for the Oracle Space Sweepstakes!
>>
> 
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> 
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>
> 
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> 		
> __________________________________ 
> Yahoo! Mail Mobile 
> Take Yahoo! Mail with you! Check email on your mobile phone. 
> http://mobile.yahoo.com/learn/mail 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click

[Springframework-developer] jstl 1.1

[Darrell K. <Da...@bo...>]

Hi Everyone,

Is there any reason why Jakarta jstl 1.1 isn't included in the dependent
libraries of Spring?

Darrell

Re: [Springframework-developer] spring Build Failed

[Juergen H. <ju...@in...>]

OK, understood - thanks, Colin. Is Alef away this week? Changing the FTP
location shouldn't be a big deal, after all...

It's just a bit of a pain that we haven't thought of this before the website
move. We need to coordinate such things better in the future.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Thursday, May 12, 2005 4:38 AM
To: spr...@li...
Subject: Re: [Springframework-developer] spring Build Failed


It's not as simple as 'someone'. Only Alef can do the work on the build
side, since it's running at JTeam. And on our end, I'm generally the
only person who's been touching our host (although Alef knows Linux of
course so could get in there), and I'm onsite at a client all this week
and can't coordinate with Alef during the day.

I think the easiest thing is for Alef to point the uploads towards
oldwww.springframework.org, which still points to the old site, and we
can easilly adjust the link from the new website to point to the upload
dir on the old one.

Then this weekend or any time after, when I am back, I can coordinate
with Alef to get the stuff going into the new site.

Colin

Juergen Hoeller wrote:

>Could someone *please* fix the FTP upload? It's really a pain that we
>haven't had a proper nightly build for a week now!
>
>I don't feel particularly confident about releasing 1.2 final without an
>up-to-date nightly build having preceded it...
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of al...@in...
>Sent: Wednesday, May 11, 2005 12:32 AM
>To: spr...@li...
>Subject: [Springframework-developer] spring Build Failed
>Importance: High
>
>
>View results here ->
>http://opensource.jteam.nl/build/buildresults/spring?log=log20050511001708
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] spring Build Failed

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

It's not as simple as 'someone'. Only Alef can do the work on the build 
side, since it's running at JTeam. And on our end, I'm generally the 
only person who's been touching our host (although Alef knows Linux of 
course so could get in there), and I'm onsite at a client all this week 
and can't coordinate with Alef during the day.

I think the easiest thing is for Alef to point the uploads towards 
oldwww.springframework.org, which still points to the old site, and we 
can easilly adjust the link from the new website to point to the upload 
dir on the old one.

Then this weekend or any time after, when I am back, I can coordinate 
with Alef to get the stuff going into the new site.

Colin

Juergen Hoeller wrote:

>Could someone *please* fix the FTP upload? It's really a pain that we
>haven't had a proper nightly build for a week now!
>
>I don't feel particularly confident about releasing 1.2 final without an
>up-to-date nightly build having preceded it...
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of al...@in...
>Sent: Wednesday, May 11, 2005 12:32 AM
>To: spr...@li...
>Subject: [Springframework-developer] spring Build Failed
>Importance: High
>
>
>View results here ->
>http://opensource.jteam.nl/build/buildresults/spring?log=log20050511001708
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

Re: [Springframework-developer] Re: OpenSessionInView and portlet support

[Rob B. <cro...@ya...>]

Why not refactor the OpenSessionInViewInterceptor  to
a new class called CommonOpenSessionInViewInterceptor
and have it operate on a set of new interfaces called
CommonRequest and CommonResponse.

Then have two separate implementations.  One is called
OpenSessionInViewInterceptor (to replace the original
and remain backward compatible with existing code). 
The other is PortletOpenSessionInViewInterceptor. 
These classes can then wrap (not extend) the
CommonOpenSessionInViewInterceptor ala the adapter
pattern.  These classes each have inner classes that
implement the web/portlet version of CommonRequest &
CommonResponse, and pass these to the
CommonOpenSessionInViewInterceptor.

End result, no code duplication, Spring web MVC is not
tied to Portlet MVC, and you no longer have to hope
that PortletRequest is really a HttpServletRequest.

Just an idea.
Rob


--- John Lewis <jl...@ar...> wrote:

> Hi.  I just ran across this thread and thought I
> would mention our 
> current solution to this issue.
> 
> As discussed, filters do not apply to portlets, nor
> should they since 
> they are for filtering servlet requests and portlets
> are really a 
> different animal.  However, the use of Spring
> interceptors works 
> perfectly for portlets and is the right way to go.
> 
> For now, we have taken advantage of a fact that I
> believe is true for 
> most/all JSR-168 portal platforms: the
> PortletRequest and 
> PortletResponse objects are also the
> HttpServletRequest and 
> HttpServletResponse objects.  Because this is true,
> we are just 
> delegating to the existing
> OpenSessionInViewInterceptor class.  This is 
> not required by the JSR-168 spec and so is not
> guaranteed to work, but 
> it has been true on all the platforms I have checked
> so far.
> 
> Below are the contents of the class we are currently
> using.  I hope you 
> find this helpful.  I'd love to hear feedback from
> others on this.  Has 
> anyone been using a portal platform where this will
> not work?
> 
> I'd like to include this class in the Portlet MVC
> framework in the 
> sandbox once we can get some motion going with that
> again.
> 
> -- John Lewis
> 
> 
> 
> /*
>  * Copyright 2002-2004 the original author or
> authors.
>  *
>  * Licensed under the Apache License, Version 2.0
> (the "License");
>  * you may not use this file except in compliance
> with the License.
>  * You may obtain a copy of the License at
>  *
>  *      http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in
> writing, software
>  * distributed under the License is distributed on
> an "AS IS" BASIS,
>  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
> either express or implied.
>  * See the License for the specific language
> governing permissions and
>  * limitations under the License.
>  */
> 
> package
> org.springframework.web.portlet.support.hibernate;
> 
> import javax.portlet.PortletRequest;
> import javax.portlet.PortletResponse;
> import javax.portlet.RenderRequest;
> import javax.portlet.RenderResponse;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
> 
> import
>
org.springframework.web.portlet.PortletControllerInterceptor;
> import
>
org.springframework.web.portlet.support.PortletController;
> import org.springframework.web.servlet.ModelAndView;
> 
> /**
>  * <p>PortletControllerInteceptor that provides
> access to an open
>  * Hibernate session in the view.</p>
>  *
>  * <p>This implementation delgates to
>  * 
>
<code>org.springframework.orm.hibernate.support.OpenSessionInViewInterceptor</code>,
>  * but this only works if the
> <code>PortletRequest</code> and 
> <code>PortletReponse</code> objects
>  * involved are also instances of
> <code>HttpServletRequest</code> and 
> <code>HttpServletReponse</code>.
>  * While most portal providers do implement their
> classes this way, it 
> is not
>  * part of the JSR-168 spec and is not guaranteed to
> work.  Be sure to test
>  * this with any target portal platforms before
> comitting to usage of this
>  * class.</p>
>  *
>  * <p>TODO: Reimplement this class as a standalone
> Interceptor without 
> the above limitation.</p>
>  *
>  * @author John Lewis
>  * @see 
>
org.springframework.orm.hibernate.support.OpenSessionInViewInterceptor
>  */
> public class OpenSessionInViewInterceptor extends
>         
>
org.springframework.orm.hibernate.support.OpenSessionInViewInterceptor
>         implements PortletControllerInterceptor {
> 
>     public boolean preController(PortletRequest
> request, PortletResponse 
> response,
>             PortletController handler) throws
> Exception {
>         if (request instanceof HttpServletRequest &&
>                 response instanceof
> HttpServletResponse)
>             return
> super.preHandle((HttpServletRequest)request, 
> (HttpServletResponse)response,
>                     (Object)handler);
>         return false;
>     }
> 
>     public void postController(RenderRequest
> request, RenderResponse 
> response,
>             PortletController handler, ModelAndView
> modelAndView) throws 
> Exception {
>         if (request instanceof HttpServletRequest &&
>                 response instanceof
> HttpServletResponse)
>            
> super.postHandle((HttpServletRequest)request, 
> (HttpServletResponse)response,
>                     (Object)handler, modelAndView);
>     }
> 
>     public void afterCompletion(PortletRequest
> request, PortletResponse 
> response,
>             PortletController handler, Exception ex)
> throws Exception {
>         if (request instanceof HttpServletRequest &&
>                 response instanceof
> HttpServletResponse)
>            
> super.afterCompletion((HttpServletRequest)request, 
> (HttpServletResponse)response,
>                     (Object)handler, ex);
>     }
> 
> }
> 
> 
> 
> 
> 
> 
> 
> J. Enrique Ruiz wrote:
> 
> > Hi,
> >
> > A Portlet is not a Servlet, a set of portlets are
> invoked directly by 
> > the portlet-container in one client request.
> >
> > The portlet spec says: "If the client request is
> triggered by an 
> > action URL, the portal/portlet-container must
> first trigger the action 
> > request by invoking the processAction method of
> the targeted portlet. 
> > The portal/portlet-container must wait until the
> action request 
> > finishes. Then, the portal/portlet-container must
> trigger the render 
> > request by invoking the render method for all the
> portlets in the 
> > portal page with the possible exception of
> portlets for which their 
> > content is being cached. The render requests may
> be executed 
> > sequentially or in parallel without any guaranteed
> order."
> >
> > Note that 'the render request may be executed IN
> PARALLEL', as I 
> > understand it, each render request could be
> executed on different 
> > threads. I think this feature advises against the
> use of 
> > OpenSessionInViewFilter class with portlets.
> >
> >> Well, if OpenSessionInViewFilter doesn't kick in
> for portlets, no other
> >> filter will kick in with portlets either. Isn't
> there maybe some general
> >> issue hiding there?
> >>
> >> Of course we can provide an
> OpenSessionInViewInterceptor for 
> >> portlets, but
> >> I'm not sure whether that's actually a good fit
> there. The Portlet 
> >> request
> >> flow with separate handle and render callbacks
> makes this less 
> >> compelling.
> >>
> >> What we certainly can't do is let the existing 
> >> OpenSessionInViewInterceptor
> >> implement some PortletControllerInterceptor
> interface. That would force
> >> every Servlet user to have the portlet.jar on the
> classpath.
> >>
> >> Juergen
> >>
> >>
> >> -----Original Message-----
> >> From:
>
spr...@li...
> >>
>
[mailto:spr...@li...]On
> Behalf
> >> Of Erwin Vervaet
> >> Sent: Tuesday, April 19, 2005 9:26 PM
> >> To:
> spr...@li...
> >> Subject: [Springframework-developer]
> OpenSessionInView and portlet
> >> support
> >>
> >>
> >> Apparently the existing OSIV filter does not work
> with portlets:
> >>
> >>
>
http://forum.springframework.org/viewtopic.php?t=4907
> >>
> >> I guess we should tackle this issue when doing
> the Portlet support 
> >> for 1.3.
> >> There is no PortletMVC category in JIRA so I'm
> not sure where to file 
> >> it...
> >> Any input from the Porlet people?
> >>
> >> Erwin Vervaet
> >> erw...@er...
> >>
> >>
> >>
> >>
>
-------------------------------------------------------
> >> This SF.Net email is sponsored by: New Crystal
> Reports XI.
> >> Version 11 adds new functionality designed to
> reduce time involved in
> >> creating, integrating, and deploying reporting
> solutions. Free 
> >> runtime info,
> >> new features, or free trial, at: 
> >> http://www.businessobjects.com/devxi/728
> >> _______________________________________________
> >> Springframework-developer mailing list
> >> Spr...@li...
> >>
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >>
> >>
>
-------------------------------------------------------
> >> This SF.Net email is sponsored by: New Crystal
> Reports XI.
> >> Version 11 adds new functionality designed to
> reduce time involved in
> >> creating, integrating, and deploying reporting
> solutions. Free 
> >> runtime info,
> >> new features, or free trial, at: 
> >> http://www.businessobjects.com/devxi/728
> >> _______________________________________________
> >> Springframework-developer mailing list
> >> Spr...@li...
> >>
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>  
> >>
> >
> >
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space
> Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
>
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 



		
__________________________________ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 

[Springframework-developer] Portlet MVC Status

[John L. <jl...@ar...>]

It's been over a month since this discussion and there is still no 
progress on merging together the contributions to the Portlet MVC 
framework.  Several of us are working with this framework on critical 
projects and would really like to start moving it forward in a reliable 
direction.

Would it be better for us to start a separate sourceforge or java.net 
project for this until we can work on merging back into Spring proper, 
or is there some light at the end of this tunnel?


> Juergen Hoeller wrote:
>
>> That sounds like a good plan to me! It would be great to get this going
>> ASAP. After all, our timeplan for Spring 1.3 is pretty aggressive, so
>> waiting till after 1.2 final might not leave enough time.
>>
>> Bill, Dmitriy, anyone volunteering to manage the sandbox code in the
>> meantime? :-) This would have to be someone with commit rights, after 
>> all,
>> and ideally someone already using the Portlet code.
>
>> First step would be to merge all existing contributions in. Let's assume
>> that the Portlet code will become part of Spring 1.3 proper (which is
>> likely), and continue to work on it in the sandbox.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On Behalf
>> Of Rainer Schmitz
>> Sent: Wednesday, March 30, 2005 11:53 AM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] Re: Portlet Form Controllers
>>
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> While the "official" work on the Portlet support are postponed to Spring
>> 1.3 I still would like to have a place for discussions and code
>> contributions. At this time the discussion is spread across this list,
>> the forum, confluence, and JIRA, which makes it hard to follow.
>>
>> As for discussions, I would propose to stick to this list - we *are*
>> talking about Spring development, and this way the experienced Spring
>> developers may take the opportunity to participate.
>>
>> As for code contributios: during the past couple of month several people
>> (William, Nick, John, and me) have contributed some code, but after each
>> contribution there was a big gap. One reason might be that it's very
>> inconvenient to get the up-to-date version of the code (none of the
>> changes made it into CVS; you have to fetch the sandbox version and copy
>> the content of several zip files from confluence). Without a proper code
>> management facility it's pointless to add more contributions.
>>
>> I'm undecided wether portlet support should be part of main Spring or a
>> sub project, but for the time being it would really help if the portlet
>> code would be located at a place where all interested people could find
>> the up-to-date version and contribute enhancements. When the official
>> work in the Spring 1.3 context begins, this code could be an
>> implementation base for any portlet code handled in the traditional way.
>>
>> What do you think?
>>
>> Rainer
>>
>>
>>
>> Juergen Hoeller schrieb:
>>
>>> John,
>>>
>>> Sorry for the late reply. Thanks for volunteering! :-)
>>>
>>> Let's continue to proceed in the Portlet area once Spring 1.2 is 
>>> out. Both
>>> Spring Web Flows and the Portlet support are currently planned to be
>>> cornerstones of Spring 1.3.
>>>
>>> Regarding commit rights, let's discuss this once 1.2 is out too. We're
>>> willing to extend the developer team, but there's a couple of things 
>>> to be
>>> clarified (CLA etc).
>>>
>>> In the meantime, feel free to create a JIRA issue for your 
>>> enhancements!
>>
>>
>> I'm
>>
>>> sure that Dmitriy, Bill and co will be happy to have an early look at
>>
>>
>> this.
>>
>>> Juergen
>>>
>>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.2.2 (MingW32)
>> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>>
>> iD8DBQFCSnb7w+xsU7A7UOgRAo39AJ9LlKn1KvEOFzItXO83+oUoUhvMHgCfWoVy
>> rv556WE9CYsBzgbrTtkRqLU=
>> =qCQl
>> -----END PGP SIGNATURE-----
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>

[Springframework-developer] Re: OpenSessionInView and portlet support

[John L. <jl...@ar...>]

Hi.  I just ran across this thread and thought I would mention our 
current solution to this issue.

As discussed, filters do not apply to portlets, nor should they since 
they are for filtering servlet requests and portlets are really a 
different animal.  However, the use of Spring interceptors works 
perfectly for portlets and is the right way to go.

For now, we have taken advantage of a fact that I believe is true for 
most/all JSR-168 portal platforms: the PortletRequest and 
PortletResponse objects are also the HttpServletRequest and 
HttpServletResponse objects.  Because this is true, we are just 
delegating to the existing OpenSessionInViewInterceptor class.  This is 
not required by the JSR-168 spec and so is not guaranteed to work, but 
it has been true on all the platforms I have checked so far.

Below are the contents of the class we are currently using.  I hope you 
find this helpful.  I'd love to hear feedback from others on this.  Has 
anyone been using a portal platform where this will not work?

I'd like to include this class in the Portlet MVC framework in the 
sandbox once we can get some motion going with that again.

-- John Lewis



/*
 * Copyright 2002-2004 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.springframework.web.portlet.support.hibernate;

import javax.portlet.PortletRequest;
import javax.portlet.PortletResponse;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.springframework.web.portlet.PortletControllerInterceptor;
import org.springframework.web.portlet.support.PortletController;
import org.springframework.web.servlet.ModelAndView;

/**
 * <p>PortletControllerInteceptor that provides access to an open
 * Hibernate session in the view.</p>
 *
 * <p>This implementation delgates to
 * 
<code>org.springframework.orm.hibernate.support.OpenSessionInViewInterceptor</code>,
 * but this only works if the <code>PortletRequest</code> and 
<code>PortletReponse</code> objects
 * involved are also instances of <code>HttpServletRequest</code> and 
<code>HttpServletReponse</code>.
 * While most portal providers do implement their classes this way, it 
is not
 * part of the JSR-168 spec and is not guaranteed to work.  Be sure to test
 * this with any target portal platforms before comitting to usage of this
 * class.</p>
 *
 * <p>TODO: Reimplement this class as a standalone Interceptor without 
the above limitation.</p>
 *
 * @author John Lewis
 * @see 
org.springframework.orm.hibernate.support.OpenSessionInViewInterceptor
 */
public class OpenSessionInViewInterceptor extends
        
org.springframework.orm.hibernate.support.OpenSessionInViewInterceptor
        implements PortletControllerInterceptor {

    public boolean preController(PortletRequest request, PortletResponse 
response,
            PortletController handler) throws Exception {
        if (request instanceof HttpServletRequest &&
                response instanceof HttpServletResponse)
            return super.preHandle((HttpServletRequest)request, 
(HttpServletResponse)response,
                    (Object)handler);
        return false;
    }

    public void postController(RenderRequest request, RenderResponse 
response,
            PortletController handler, ModelAndView modelAndView) throws 
Exception {
        if (request instanceof HttpServletRequest &&
                response instanceof HttpServletResponse)
            super.postHandle((HttpServletRequest)request, 
(HttpServletResponse)response,
                    (Object)handler, modelAndView);
    }

    public void afterCompletion(PortletRequest request, PortletResponse 
response,
            PortletController handler, Exception ex) throws Exception {
        if (request instanceof HttpServletRequest &&
                response instanceof HttpServletResponse)
            super.afterCompletion((HttpServletRequest)request, 
(HttpServletResponse)response,
                    (Object)handler, ex);
    }

}







J. Enrique Ruiz wrote:

> Hi,
>
> A Portlet is not a Servlet, a set of portlets are invoked directly by 
> the portlet-container in one client request.
>
> The portlet spec says: "If the client request is triggered by an 
> action URL, the portal/portlet-container must first trigger the action 
> request by invoking the processAction method of the targeted portlet. 
> The portal/portlet-container must wait until the action request 
> finishes. Then, the portal/portlet-container must trigger the render 
> request by invoking the render method for all the portlets in the 
> portal page with the possible exception of portlets for which their 
> content is being cached. The render requests may be executed 
> sequentially or in parallel without any guaranteed order."
>
> Note that 'the render request may be executed IN PARALLEL', as I 
> understand it, each render request could be executed on different 
> threads. I think this feature advises against the use of 
> OpenSessionInViewFilter class with portlets.
>
>> Well, if OpenSessionInViewFilter doesn't kick in for portlets, no other
>> filter will kick in with portlets either. Isn't there maybe some general
>> issue hiding there?
>>
>> Of course we can provide an OpenSessionInViewInterceptor for 
>> portlets, but
>> I'm not sure whether that's actually a good fit there. The Portlet 
>> request
>> flow with separate handle and render callbacks makes this less 
>> compelling.
>>
>> What we certainly can't do is let the existing 
>> OpenSessionInViewInterceptor
>> implement some PortletControllerInterceptor interface. That would force
>> every Servlet user to have the portlet.jar on the classpath.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On Behalf
>> Of Erwin Vervaet
>> Sent: Tuesday, April 19, 2005 9:26 PM
>> To: spr...@li...
>> Subject: [Springframework-developer] OpenSessionInView and portlet
>> support
>>
>>
>> Apparently the existing OSIV filter does not work with portlets:
>>
>> http://forum.springframework.org/viewtopic.php?t=4907
>>
>> I guess we should tackle this issue when doing the Portlet support 
>> for 1.3.
>> There is no PortletMVC category in JIRA so I'm not sure where to file 
>> it...
>> Any input from the Porlet people?
>>
>> Erwin Vervaet
>> erw...@er...
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: New Crystal Reports XI.
>> Version 11 adds new functionality designed to reduce time involved in
>> creating, integrating, and deploying reporting solutions. Free 
>> runtime info,
>> new features, or free trial, at: 
>> http://www.businessobjects.com/devxi/728
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: New Crystal Reports XI.
>> Version 11 adds new functionality designed to reduce time involved in
>> creating, integrating, and deploying reporting solutions. Free 
>> runtime info,
>> new features, or free trial, at: 
>> http://www.businessobjects.com/devxi/728
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>  
>>
>
>

RE: [Springframework-developer] Declarative Validation Framework in Spring's Future?

[Oliver H. <Ol...@ou...>]

Steven,

> I didn't know Keith had plans for a declarative validation solution.
> I'm looking forward to hear his ideas on the subject.

Keith's already started work on his declarative validation framework!
The code is in the sandbox's org.springframework.rules package. There's
also a page about it in the wiki:
http://opensource.atlassian.com/confluence/spring/display/DOC/Declarativ
e+Validation?focusedCommentId=3D132

From my (very brief) look at what you've done with Valang it appears
there is a strong synergy between the 2 projects. Your functions and
predicates packages have a lot of similarities with Keith's closure and
constraint packages. I suspect that it wouldn't be hard to reimplement
your Valang parser so that it generated Keith's Rules.=20


Ollie

[Springframework-developer] spring Build Failed

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050512001546

Re: [Springframework-developer] Declarative Validation Framework in Spring's Future?

[Steven D. <ste...@gm...>]

SGkgTWF0dCwKClZhbGFuZyB2YWxpZGF0b3IgaXMgY3VycmVudGx5IHNjaGVkdWxlZCBmb3IgcmVs
ZWFzZSB3aXRoIHNwcmluZwptb2R1bGVzIDAuMyAodGhlIDAuMiByZWxlYXNlIGlzIGN1cnJlbnRs
eSBwZW5kaW5nKS4KCkFzIGFuIGFjdGl2ZSBtZW1iZXIgb2YgdGhlIGRlY2xhcmF0aXZlIHZhbGlk
YXRpb24gZnJvbnQgSSB3b3VsZCBoYXJkbHkKY2FsbCBpcyBhIGZyb250LiBJIGZlZWwgaXQncyBy
b3VnaCB0ZXJyYWluIHNjYXR0ZXJlZCB3aXRoIHNvbHV0aW9ucywKaWRlYXMgYW5kIG9waW5pb25z
LiBJdCBhbHNvIGZlZWxzIGxpa2UgYSB2ZXJ5IGxvbmVseSBwbGFjZSB0aGF0IEkgbGlrZQphIGxv
dC4KClZhbGFuZyBpcyBub3RoaW5nIG1vcmUgdGhhbiBteSBleHByZXNzaW9uIG9mIGhvdyBkZWNs
YXJhdGl2ZQp2YWxpZGF0aW9uIHNob3VsZCBiZSBkb25lLiBXaGlsZSBwcm9iYWJseSBub3QgdGhl
IHRoZSBiZXN0IHBvc3NpYmxlCnNvbHV0aW9uIGl0J3MgY3VycmVudGx5IHRoZSBvbmx5IHRoaW5n
IEkgY291bGQgY29tZSB1cCB3aXRoLiBJdCdzIGFsc28KdGhlIGZpcnN0ICg/KSBhdHRlbXB0IHRv
IGNyZWF0ZSBhIG5ldyBzb2x1dGlvbiB3aXRob3V0IHJlbHlpbmcgb24KZXhpc3RpbmcgdG9vbHMu
IEl0IHJlcXVpcmVzIGdldHRpbmcgdXNlZCB0byB3aGljaCBpcyB0aGUgZHJhd2JhY2sgKGl0CmFs
c28gcmVxdWlyZXMgd3JpdGluZyBkb2N1bWVudGF0aW9uIHdoaWNoIEkgY29uc2lkZXIgYW5vdGhl
cgpkcmF3YmFjaykuIEl0IG1heSBzcHVyIG90aGVyIGF0dGVtcHRzIG9yIGF0IGxlYXN0IHByb3Zp
ZGVzIGEgYml0IG9mCmlubm92YXRpb24gb2YgdGhlIHN0aWxsIHZlcnkgd2VhayBmcm9udCB3aGlj
aCBJIGNvbnNpZGVyIGFuIGFkdmFudGFnZS4KCkkgY29uc2lkZXIgdGhlIGNvbW1vbnMgdmFsaWRh
dG9yIGludGVncmF0aW9uIGNvZGUgZXhhY3RseSB0aGF0OiB0aGUKb25seSBuZXcgZmVhdHVyZSBp
cyB0aGUgU3ByaW5nIGludGVncmF0aW9uLiBJdCBkb2Vzbid0IG9mZmVyIG5vdmVsIG5ldwp3YXlz
IG9mIGRvaW5nIHZhbGlkYXRpb24gYW5kIGJlY2F1c2Ugb2YgdGhhdCBJIGZpbmQgaXQgYm9yaW5n
LiBJCnN0YXJ0ZWQgcmVhZGluZyB0aGUgY29tbW9ucyB2YWxpZGF0b3IgY2hhcHRlciBvZiB0aGUg
dXBjb21pbmcgSmFrYXJ0YQpDb21tb25zIE9ubGluZSBCb29rc2hlbGYgcHVibGlzaGVkIGJ5IE1h
bm5pbmcgYW5kIGl0IGdhdmUgbWUgYQpoZWFkYWNoZS4gSSBmaW5kIGl0IHRvbyBjb21wbGV4IHRv
IHNldCB1cCBhbmQgdXNlLgoKSSBkaWRuJ3Qga25vdyBLZWl0aCBoYWQgcGxhbnMgZm9yIGEgZGVj
bGFyYXRpdmUgdmFsaWRhdGlvbiBzb2x1dGlvbi4KSSdtIGxvb2tpbmcgZm9yd2FyZCB0byBoZWFy
IGhpcyBpZGVhcyBvbiB0aGUgc3ViamVjdC4KCkknbSBub3Qgc3VyZSB0aGlzIGNhbiBoZWxwIHlv
dSBpbiBhbnkgd2F5IGJ1dCBJIGRpZG4ndCB3YW50IHRvIHRha2UKdGhlIHJpc2sgb2Ygbm90IGxl
dHRpbmcgeW91IGtub3cuCgpTdGV2ZW4KCgpPbiA1LzkvMDUsIE1hdHQgUmFpYmxlIDxsaXN0c0By
YWlibGVkZXNpZ25zLmNvbT4gd3JvdGU6Cj4gSGV5IGd1eXMsCj4gCj4gSSBoYXZlIHRoZSBmb2xs
b3dpbmcgc2VjdGlvbiBpbiBvbmUgb2YgbXkgU3ByaW5nIExpdmUgY2hhcHRlcnMuICBJCj4gaGF2
ZW4ndCBzZWVuIG11Y2ggYWN0aXZpdHkgb24gdGhlICJkZWNsYXJhdGl2ZSB2YWxpZGF0aW9uIiBm
cm9udCBpbgo+IFNwcmluZyBNVkMgLSBzbyBJIHdhbnQgdG8gbWFrZSBzdXJlIHRoaXMgaXMgc3Rp
bGwgdmFsaWQuCj4gCj4gVGhhbmtzLAo+IAo+IE1hdHQKPiAKPiBTcHJpbmcncyBGdXR1cmUgRGVj
bGFyYXRpdmUgVmFsaWRhdGlvbiBGcmFtZXdvcmsKPiBBdCB0aGUgdGltZSBvZiB0aGlzIHdyaXRp
bmcsIENvbW1vbnMgVmFsaWRhdG9yIGlzIHRoZSBvbmx5IGRlY2xhcmF0aXZlCj4gdmFsaWRhdGlv
biBmcmFtZXdvcmsgdGhhdCdzIGJlZW4gcmVsZWFzZWQgdG8gc3VwcG9ydCBTcHJpbmcgTVZDLiBU
aGVyZQo+IGlzIGFub3RoZXIgZGVjbGFyYXRpdmUgdmFsaWRhdG9yICh0aGUgVmFsYW5nIFZhbGlk
YXRvcikgdGhhdCdzIHBhcnQgb2YKPiB0aGUgU3ByaW5nIE1vZHVsZXMgcHJvamVjdCwgYnV0IGl0
IGhhc24ndCBiZWVuIHJlbGVhc2VkIHlldC4gIEFzIGZhciBhcwo+IGRlY2xhcmF0aXZlIHZhbGlk
YXRpb24gYmVpbmcgcGFydCBvZiBTcHJpbmcgLSB0aGVyZSBhcmUgcGxhbnMgZm9yIGl0LAo+IGJ1
dCBpdCBoYXNuJ3QgYmVlbiBkZXZlbG9wZWQgeWV0LiBJIGFza2VkIEtlaXRoIERvbmFsZCB0byBw
cm92aWRlIG1lCj4gd2l0aCBhIGZldyBkZXRhaWxzIGFib3V0IGl0LCBhbmQgaGVyZSBhcmUgdGhl
IGtleQo+IGZlYXR1cmVzL2RpZmZlcmVudGlhdG9ycyBoZSBzZW50IG1lOgo+IJUgICAgICAgQSBz
aW1wbGUsIGNvbnNpc3RlbnQgaW50ZXJmYWNlIGZvciBkZWZpbmluZyBuZXcgdmFsaWRhdGlvbiBy
dWxlcwo+IChydWxlIHByb3ZpZGVycyBzaW1wbHkgaW1wbGVtZW50IGEgc2luZ2xlICJib29sZWFu
IHRlc3QoYXJndW1lbnQpIgo+IG1ldGhvZCkuCj4glSAgICAgICBTdXBwb3J0IGZvciBiZWFuIHBy
b3BlcnR5IGV4cHJlc3Npb25zIChmb3IgZXhhbXBsZSwgbWluUHJvcGVydHkgbXVzdAo+IGJlIGxl
c3MgdGhhbiBtYXhQcm9wZXJ0eSkuIFRoZSBwcm9wZXJ0eSBhY2Nlc3Mgc3RyYXRlZ3kgd2lsbCBi
ZQo+IHBsdWdnYWJsZSBhbmQgbm90IGxpbWl0ZWQgdG8gamF2YSBiZWFucyAoZm9yIGV4YW1wbGUs
IGFsbG93aW5nCj4gbWFwLWJhY2tlZCBzdG9yYWdlLCBvciBidWZmZXJlZCAiZm9ybSBvYmplY3Rz
IiBvbiB0aGUgcmljaCBjbGllbnQgc2lkZQo+IG9mIHRoZSBob3VzZSkuCj4glSAgICAgICBTdXBw
b3J0IGZvciBjb21wbGV4IG5lc3RlZCBleHByZXNzaW9ucyAoYW5kL29yL25vdCksIGFuZCBhbGwK
PiByZWxhdGlvbmFsIG9wZXJhdG9ycyAoPiwgPj0sIDwsIDw9LCAhPSwgPT0pLgo+IJUgICAgICAg
U3VwcG9ydCBmb3IgYXBwbHlpbmcgZGlmZmVyZW50IHNldHMgb2YgcnVsZXMgYmFzZWQgb24gY29u
dGV4dCBvcgo+IHVzZS1jYXNlLgo+IJUgICAgICAgQSByZXBvcnRpbmcgc3Vic3lzdGVtIGNhcGFi
bGUgb2YgaXRlcmF0aW5nIG92ZXIgcnVsZSBzdHJ1Y3R1cmVzLAo+IHBlcmZvcm1pbmcgdmFsaWRh
dGlvbiwgYW5kIGNhcHR1cmluZy9nZW5lcmF0aW5nIGVycm9yIG1lc3NhZ2UgcmVzdWx0cy4KPiBU
aGlzIGFsbG93cyB5b3UgdG8gYXNzZW1ibGUgY29tcGxleCBydWxlcyBvbi10aGUtZmx5IHdpdGhv
dXQgaGF2aW5nIHRvCj4gaGFyZCBjb2RlIGEgbG90IG9mIHN0YXRpYyBtZXNzYWdlczsgdGhlIHJl
cG9ydGVyIGlzIGNhcGFibGUgb2YKPiBnZW5lcmF0aW5nIHJ1bGUgbWVzc2FnZXMgZnJvbSB0aGUg
dW5kZXJseWluZyBzdHJ1Y3R1cmVzIGF1dG9tYXRpY2FsbHkuCj4glSAgICAgICBSZXBvcnQgZmll
bGQgdHlwaW5nIGhpbnRzICh0aGUgcnVsZXMgYXNzb2NpYXRlZCB3aXRoIGEgZmllbGQgdG8gbGV0
Cj4gdGhlIHVzZXIga25vdyB3aGF0IHRoZXkncmUgZXhwZWN0ZWQgdG8gdHlwZSkuCj4glSAgICAg
ICBJbnRlZ3JhdGlvbiB3aXRoIFNwcmluZyBSaWNoIENsaWVudCBQbGF0Zm9ybSAoUkNQKSBhbmQg
U3ByaW5nIE1WQwo+IGVudmlyb25tZW50cy4KPiAKPiAKCgotLSAKIklmIHlvdSB3YW50IHRvIGJl
IGEgZGlmZmVyZW50IGZpc2gsIHlvdSBnb3R0YSBqdW1wIG91dCBvZiB0aGUgc2Nob29sLiIKLS0g
Q2FwdGFpbiBCZWVmaGVhcnQK

Re: [Springframework-developer] Declarative Validation Framework in Spring's Future?

[Steven D. <ste...@gm...>]

VGhlIHZhbGFuZyB2YWxpZGF0b3IgaW1wbGVtZW50cyB0aGUKb3JnLnNwcmluZ2ZyYW1ld29yay52
YWxpZGF0aW9uLlZhbGlkYXRvciBpbnRlcmZhY2UuIEFzIHN1Y2ggaXQgY2FuIGJlCnVzZWQgaW5k
ZXBlbmRlbnRseSBvZiBTcHJpbmcgTVZDLgoKT24gNS8xMC8wNSwgTWljaGFlbCBFLiBNb29yZXMg
PG1tb29yZXNAcmVhbC5jb20+IHdyb3RlOgo+IElzIFZhbGFuZyBhYnN0cmFjdGVkIGZyb20gTVZD
IGFuZCBodHRwIHJlcXVlc3RzPwo+IEkgbmVlZCBhIHZhbGlkYXRvciB0aGF0IEkgY2FuIHBsdWcg
aW50byBteSBQT0pPcywgd2hpY2ggYXJlIGFwcCBzZXJ2ZXIKPiBjbGFzc2VzLAo+IE5PVCB3ZWIg
c2VydmVyIGNsYXNzZXMuCj4gCj4gTWF0dCBSYWlibGUgd3JvdGU6Cj4gCj4gPiBIZXkgZ3V5cywK
PiA+Cj4gPiBJIGhhdmUgdGhlIGZvbGxvd2luZyBzZWN0aW9uIGluIG9uZSBvZiBteSBTcHJpbmcg
TGl2ZSBjaGFwdGVycy4gSQo+ID4gaGF2ZW4ndCBzZWVuIG11Y2ggYWN0aXZpdHkgb24gdGhlICJk
ZWNsYXJhdGl2ZSB2YWxpZGF0aW9uIiBmcm9udCBpbgo+ID4gU3ByaW5nIE1WQyAtIHNvIEkgd2Fu
dCB0byBtYWtlIHN1cmUgdGhpcyBpcyBzdGlsbCB2YWxpZC4KPiA+Cj4gPiBUaGFua3MsCj4gPgo+
ID4gTWF0dAo+ID4KPiA+ICpTcHJpbmcncyBGdXR1cmUgRGVjbGFyYXRpdmUgVmFsaWRhdGlvbiBG
cmFtZXdvcmsKPiA+ICpBdCB0aGUgdGltZSBvZiB0aGlzIHdyaXRpbmcsIENvbW1vbnMgVmFsaWRh
dG9yIGlzIHRoZSBvbmx5Cj4gPiBkZWNsYXJhdGl2ZSB2YWxpZGF0aW9uIGZyYW1ld29yayB0aGF0
J3MgYmVlbiByZWxlYXNlZCB0byBzdXBwb3J0Cj4gPiBTcHJpbmcgTVZDLiBUaGVyZSBpcyBhbm90
aGVyIGRlY2xhcmF0aXZlIHZhbGlkYXRvciAodGhlIF9WYWxhbmcKPiA+IFZhbGlkYXRvcl8pIHRo
YXQncyBwYXJ0IG9mIHRoZSBTcHJpbmcgTW9kdWxlcyBwcm9qZWN0LCBidXQgaXQgaGFzbid0Cj4g
PiBiZWVuIHJlbGVhc2VkIHlldC4gQXMgZmFyIGFzIGRlY2xhcmF0aXZlIHZhbGlkYXRpb24gYmVp
bmcgcGFydCBvZgo+ID4gU3ByaW5nIC0gdGhlcmUgYXJlIHBsYW5zIGZvciBpdCwgYnV0IGl0IGhh
c24ndCBiZWVuIGRldmVsb3BlZCB5ZXQuIEkKPiA+IGFza2VkIEtlaXRoIERvbmFsZCB0byBwcm92
aWRlIG1lIHdpdGggYSBmZXcgZGV0YWlscyBhYm91dCBpdCwgYW5kIGhlcmUKPiA+IGFyZSB0aGUg
a2V5IGZlYXR1cmVzL2RpZmZlcmVudGlhdG9ycyBoZSBzZW50IG1lOgo+ID4glSBBIHNpbXBsZSwg
Y29uc2lzdGVudCBpbnRlcmZhY2UgZm9yIGRlZmluaW5nIG5ldyB2YWxpZGF0aW9uIHJ1bGVzCj4g
PiAocnVsZSBwcm92aWRlcnMgc2ltcGx5IGltcGxlbWVudCBhIHNpbmdsZSAiYm9vbGVhbiB0ZXN0
KGFyZ3VtZW50KSIKPiA+IG1ldGhvZCkuCj4gPiCVIFN1cHBvcnQgZm9yIGJlYW4gcHJvcGVydHkg
ZXhwcmVzc2lvbnMgKGZvciBleGFtcGxlLCBtaW5Qcm9wZXJ0eSBtdXN0Cj4gPiBiZSBsZXNzIHRo
YW4gbWF4UHJvcGVydHkpLiBUaGUgcHJvcGVydHkgYWNjZXNzIHN0cmF0ZWd5IHdpbGwgYmUKPiA+
IHBsdWdnYWJsZSBhbmQgbm90IGxpbWl0ZWQgdG8gamF2YSBiZWFucyAoZm9yIGV4YW1wbGUsIGFs
bG93aW5nCj4gPiBtYXAtYmFja2VkIHN0b3JhZ2UsIG9yIGJ1ZmZlcmVkICJmb3JtIG9iamVjdHMi
IG9uIHRoZSByaWNoIGNsaWVudCBzaWRlCj4gPiBvZiB0aGUgaG91c2UpLgo+ID4glSBTdXBwb3J0
IGZvciBjb21wbGV4IG5lc3RlZCBleHByZXNzaW9ucyAoYW5kL29yL25vdCksIGFuZCBhbGwKPiA+
IHJlbGF0aW9uYWwgb3BlcmF0b3JzICg+LCA+PSwgPCwgPD0sICE9LCA9PSkuCj4gPiCVIFN1cHBv
cnQgZm9yIGFwcGx5aW5nIGRpZmZlcmVudCBzZXRzIG9mIHJ1bGVzIGJhc2VkIG9uIGNvbnRleHQg
b3IKPiA+IHVzZS1jYXNlLgo+ID4glSBBIHJlcG9ydGluZyBzdWJzeXN0ZW0gY2FwYWJsZSBvZiBp
dGVyYXRpbmcgb3ZlciBydWxlIHN0cnVjdHVyZXMsCj4gPiBwZXJmb3JtaW5nIHZhbGlkYXRpb24s
IGFuZCBjYXB0dXJpbmcvZ2VuZXJhdGluZyBlcnJvciBtZXNzYWdlIHJlc3VsdHMuCj4gPiBUaGlz
IGFsbG93cyB5b3UgdG8gYXNzZW1ibGUgY29tcGxleCBydWxlcyBvbi10aGUtZmx5IHdpdGhvdXQg
aGF2aW5nIHRvCj4gPiBoYXJkIGNvZGUgYSBsb3Qgb2Ygc3RhdGljIG1lc3NhZ2VzOyB0aGUgcmVw
b3J0ZXIgaXMgY2FwYWJsZSBvZgo+ID4gZ2VuZXJhdGluZyBydWxlIG1lc3NhZ2VzIGZyb20gdGhl
IHVuZGVybHlpbmcgc3RydWN0dXJlcyBhdXRvbWF0aWNhbGx5Lgo+ID4glSBSZXBvcnQgZmllbGQg
dHlwaW5nIGhpbnRzICh0aGUgcnVsZXMgYXNzb2NpYXRlZCB3aXRoIGEgZmllbGQgdG8gbGV0Cj4g
PiB0aGUgdXNlciBrbm93IHdoYXQgdGhleSdyZSBleHBlY3RlZCB0byB0eXBlKS4KPiA+IJUgSW50
ZWdyYXRpb24gd2l0aCBTcHJpbmcgUmljaCBDbGllbnQgUGxhdGZvcm0gKFJDUCkgYW5kIFNwcmlu
ZyBNVkMKPiA+IGVudmlyb25tZW50cy4KPiAKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gVGhpcyBTRi5OZXQgZW1haWwgaXMgc3BvbnNv
cmVkIGJ5IE9yYWNsZSBTcGFjZSBTd2VlcHN0YWtlcwo+IFdhbnQgdG8gYmUgdGhlIGZpcnN0IHNv
ZnR3YXJlIGRldmVsb3BlciBpbiBzcGFjZT8KPiBFbnRlciBub3cgZm9yIHRoZSBPcmFjbGUgU3Bh
Y2UgU3dlZXBzdGFrZXMhCj4gaHR0cDovL2Fkcy5vc2RuLmNvbS8/YWRfaWRzOTMmYWxsb2NfaWQW
MjgxJm9wY2xpY2sKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwo+IFNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0Cj4gU3ByaW5nZnJh
bWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKPiBodHRwczovL2xpc3RzLnNv
dXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyCj4g
Cj4gCgoKLS0gCiJJZiB5b3Ugd2FudCB0byBiZSBhIGRpZmZlcmVudCBmaXNoLCB5b3UgZ290dGEg
anVtcCBvdXQgb2YgdGhlIHNjaG9vbC4iCi0tIENhcHRhaW4gQmVlZmhlYXJ0Cg==

Re: [Springframework-developer] spring Build Failed

[Juergen H. <ju...@in...>]

Could someone *please* fix the FTP upload? It's really a pain that we
haven't had a proper nightly build for a week now!

I don't feel particularly confident about releasing 1.2 final without an
up-to-date nightly build having preceded it...

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of al...@in...
Sent: Wednesday, May 11, 2005 12:32 AM
To: spr...@li...
Subject: [Springframework-developer] spring Build Failed
Importance: High


View results here ->
http://opensource.jteam.nl/build/buildresults/spring?log=log20050511001708


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer