springframework-developer Mailing List for Spring Framework (Page 142)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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

Actually, Spring's JMX support is already built to support JMX 1.0 wherever
possible. It should only require JMX 1.2 for proxy-based JMX MBean access
(the org.springframework.jmx.access package). Everything else should work
nicely on JMX 1.0 too, in particular exposure of Spring beans as MBeans.

Juergen

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf Of
Gonzales, Fabian
Sent: Tuesday, April 05, 2005 11:20 PM
To: spr...@li...
Subject: [Springframework-developer] Spring 1.2 and JMX 1.0

I am working on adding JMX support to our software, and would like to use
the JMX support in the 1.2 release of the Spring Framework. However, there
is a requirement to use WebLogic 8.1, which only supports JMX 1.0. From what
I understand Spring 1.2 only supports JMX 1.2. Are there any plans to
support JMX 1.0 in the future? If yes, what does the timeline look like?

If I decide to add JMX 1.0 support myself, how involved would it be, and
what would be the best way to add JMX 1.0 support while ensuring maximum
compatibility with future Spring releases?

- Fabian

I am working on adding JMX support to our software, and would like to
use the JMX support in the 1.2 release of the Spring Framework. However,
there is a requirement to use WebLogic 8.1, which only supports JMX 1.0.
From what I understand Spring 1.2 only supports JMX 1.2. Are there any
plans to support JMX 1.0 in the future? If yes, what does the timeline
look like?
=20
If I decide to add JMX 1.0 support myself, how involved would it be, and
what would be the best way to add JMX 1.0 support while ensuring maximum
compatibility with future Spring releases?
=20
- Fabian
=20

I've done a lot of experimenting with the Portlet support in the MVC 
packages of the sandbox (I guess informally being called Spring Portlet 
MVC) through the course of doing other things over the last few months.

The one thing that has bugged me more then any other thing is why are 
the two methods of PortletController both called "handleRequest" ?
These two methods roughly equate to the action and render methods of the 
  Portlet contract.  It seems the current trend in the industry to to 
avoid overloading, especially where it's confusing.  And in this case we 
have two very different activities going by the same name.  This seems 
wrong.

I understand the Web MVC (intended for servlet based applications) has a 
single 'handleRequest' method.  So the desire to use the same name might 
have come from there.  But, a servlet based environment does not define 
two distinct behaviors of 'action' and 'render'.

I know this code has been out there for a while and many people have 
built applications around it.  But is this something we should look at 
changing?  It would seem a framework like Spring, which exists to help 
people follow best practices like IoC, should itself, follow good 
practices like avoiding confusing use of overloading (see Effective 
Java, Item 26, page 130).

---- Cris J H

====
This message and any attachments are confidential. Unauthorized use
or disclosure of this message is strictly prohibited, and this message
must be destroyed immediately if received by an unauthorized recipient.
====

I am running into issues preparing a simple flow execution test sample for
the phonebook app.  Specifically I need the following:

- the ability to DISABLE dependency checking by object for the autowired
test - sometimes defaults really do make sense, why always require a set
method to be called for each public setter?

- the ability to turn off/on transaction management - right now
AbstractFlowExecutionTests is runnable only in the context of a database
transaction.  While this is great and all, if I want to integration test
flows outside of any transactional context, I'm screwed.  I can't exactly
subclass DependencyInjectedContextTests, as I still WANT THE OPTION of being
able to test flows in a transaction context - for the flows that demand it.
But the current structure doesn't give me that choice.

Keith

Keith Donald

Interface21 - http://www.springframework.com
<http://www.springframework.com/>  - Spring Training, Consulting and Support
- "From the Source"

Alexandru Popescu wrote:
> [quote Alexandru Popescu::on 3/28/2005 10:18 AM]
> 
>>Hi!
>>
>>I am trying to implement a more fine-grained declarative transaction support for Spring based on
>>AspectWerkz. While the things are looking pretty clean I would like to ask you how I can drive some
>>small benchmark upon the declarative transaction support offered by Spring?
>>
>>Details:
>>what I really need is some why to quantify the time spent by TransactionInterceptor.invoke method as
>>against a method call and an AspectWerkz advised method call. Most probably, my need is to have a
>>new TransactionProxyFactoryBean using a dummy TransactionInterceptor.
What's the value of benchmarking just advice overhead where transaction 
management is concerned? Actually enlisting the resources is likely to 
be the key cost, and the other overhead is less significant.

I would suggest the benchmarks don't use a mock transaction interceptor 
as in your code below, but the real Spring TransactionInterceptor and a 
real PlatformTransactionManager.

R

>>
>>Pls let me know if such a thing is already existing in the current codebase (maybe in the tests) or
>>if i am looking at the problem from a bad angle.
>>
>>tia,
>>--
>>:alex |.::the_mindstorm::.|
>>
>>ps: i will publish my result (including the AW code) as soon as i will be able to drive this small
>>benchmark.
>>
>>
>>-------------------------------------------------------
>>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
>>
>>
> 
> I would like to ask you if this is the correct way to set up a proxied invocation with Spring:
> 
> public interface ITransactionable {
>     void publicMethod();
> }
> 
> public class MockTransactionable implements ITransactionable {
>     public void publicMethod() {
>     }
> }
> 
> public class MockTransactionInterceptor implements MethodInterceptor {
>     public Object invoke(MethodInvocation method) throws Throwable {
>         return method.proceed();
>     }
> 
> }
> 
> ProxyFactory proxyFactory = new ProxyFactory(new Class[] {ITransactionable.class});
> proxyFactory.setTarget(new MockTransactionable());
> proxyFactory.addAdvice(new MockTransactionInterceptor());
> ITransactionable springProxy = (ITransactionable) proxyFactory.getProxy();
> 
> 
> tia,
> --
> :alex |.::the_mindstorm::.|
> 
> 
> -------------------------------------------------------
> 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
> 

-- 
Rod Johnson
Interface21 - Spring Services from the Source
http://www.springframework.com

Founder, Spring Framework:
http://www.springframework.org

Author, "Expert One-on-One J2EE Development Without EJB"
(May 2004, with Juergen Hoeller).
http://www.amazon.com/exec/obidos/ASIN/0764558315/

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

____________________________________________________
Interface21 Limited
Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY
Registered in England and Wales No. 5187766
____________________________________________________

Alexandru Popescu wrote:
> [quote Alexandru Popescu::on 3/28/2005 10:18 AM]
> 
>>Hi!
>>
>>I am trying to implement a more fine-grained declarative transaction support for Spring based on
>>AspectWerkz. While the things are looking pretty clean I would like to ask you how I can drive some
>>small benchmark upon the declarative transaction support offered by Spring?

You should be able to subclass TransactionAspectSupport. I pulled it out 
in 1.1 to allow AspectJ or AspectWerkz aspects to provide Spring 
transaction advice.

All,

I've integrated portlet support into the Spring Web Flow system that is 
currently in the sandbox. This support builds on the Spring Portlet MVC code 
that is also in the sandbox.

Most credit goes to J.Enrique Ruiz for contributing the code!

I know very little about portlets myself so I would like to ask all Portlet 
gurus reading this to take a look at the code and let me know if there are 
things we can improve. The code lives in the following packages in the 
sandbox:
org.springframework.web.flow.action.portlet
org.springframework.web.flow.execution.portlet
org.springframework.web.flow.portlet

Enrique:
Could you take a look at the code and provide me with answers to the 
questions I put in "TODO" markers?
Also note that I refactored the SetHelpModeAction/SetViewModeAction into a 
single class: SetPortletModeAction.
The only missing feature is support for "multipart portlet requests" (e.g. 
for file uploads), if such a thing even exists.
Finally, if you could update your Porlet PhoneBook sample and verify that it 
is still working properly. Once that's done I'll also add that to the 
webflow samples.

Erwin Vervaet
erw...@er... 

Actually, the web.flow (main) packages are now protocol independent and the 
servlet support resides in web.flow.execution.servlet. That's why we were 
proposing web.flow.execution.portlet. Since the portlet support also 
involves some portlet specific actions, which is not the case for the 
servlet support, we were proposing the additional package 
web.flow.action.portlet.

Anyway, since everybody seems to like the idea of the SWF portlet support 
being part of SWF (iso Spring Portlet MVC), I'll add it in using packages:
org.springframework.web.flow.execution.portlet
org.springframework.web.flow.action.portlet

Erwin Vervaet
erw...@er...
----- Original Message ----- 
From: "Juergen Hoeller" <ju...@in...>
To: <spr...@li...>
Sent: Monday, April 04, 2005 10:25 PM
Subject: Re: [Springframework-developer] SWF - portlet packaging

>I agree that it makes most sense to keep the Flow Portlet support within 
>the
> flow packages. After all, the Servlet version of Web Flow resides in the
> "web.flow" package too, instead of within "web.servlet"; I would argue 
> that
> the same should apply to the Portlet version.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Colin Sampaleanu
> Sent: Monday, April 04, 2005 10:03 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] SWF - portlet packaging
>
>
> Erwin Vervaet wrote:
>
>> All,
>>
>> We're preparing to integrate the Portlet support (contributed by
>> J.Enrique Ruiz) into the Web Flow system. This brings up an
>> interesting question: what packages should we use?
>>
>> Should the SWF portlet support live in the SWF packages? For instance:
>> org.springframework.web.flow.action.portlet
>> org.springframework.web.flow.execution.portlet
>>
>> Or should it live in the Spring Portlet MVC support:
>> org.springframework.web.portlet.flow
>>
>> Any input on this would be much appreciated!
>> Keith and I are currently leaning towards option 1: put it in SWF.
>
> I consider the 'integration' support for the flow as almost a
> third-party, bridging library. I think #1 makes the most sense, with the
> possibility that at some time it might even be broken out into its own
> build, although still in the same packages. This does imply that if Web
> Flow moves to the main source for 1.3, as expected, so will the portlet
> code.
>
> Colin
>
> --
> Colin Sampaleanu
> Interface21 Principal Consultant
> Spring Training, Consulting and Support - "From the Source"
> http://www.springframework.com
>
>
>
> -------------------------------------------------------
> 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
>
> 

I agree that it makes most sense to keep the Flow Portlet support within the
flow packages. After all, the Servlet version of Web Flow resides in the
"web.flow" package too, instead of within "web.servlet"; I would argue that
the same should apply to the Portlet version.

Juergen

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Monday, April 04, 2005 10:03 PM
To: spr...@li...
Subject: Re: [Springframework-developer] SWF - portlet packaging

Erwin Vervaet wrote:

> All,
>
> We're preparing to integrate the Portlet support (contributed by
> J.Enrique Ruiz) into the Web Flow system. This brings up an
> interesting question: what packages should we use?
>
> Should the SWF portlet support live in the SWF packages? For instance:
> org.springframework.web.flow.action.portlet
> org.springframework.web.flow.execution.portlet
>
> Or should it live in the Spring Portlet MVC support:
> org.springframework.web.portlet.flow
>
> Any input on this would be much appreciated!
> Keith and I are currently leaning towards option 1: put it in SWF.

I consider the 'integration' support for the flow as almost a
third-party, bridging library. I think #1 makes the most sense, with the
possibility that at some time it might even be broken out into its own
build, although still in the same packages. This does imply that if Web
Flow moves to the main source for 1.3, as expected, so will the portlet
code.

Colin

--
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

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

Erwin Vervaet wrote:

> All,
>
> We're preparing to integrate the Portlet support (contributed by 
> J.Enrique Ruiz) into the Web Flow system. This brings up an 
> interesting question: what packages should we use?
>
> Should the SWF portlet support live in the SWF packages? For instance:
> org.springframework.web.flow.action.portlet
> org.springframework.web.flow.execution.portlet
>
> Or should it live in the Spring Portlet MVC support:
> org.springframework.web.portlet.flow
>
> Any input on this would be much appreciated!
> Keith and I are currently leaning towards option 1: put it in SWF.

I consider the 'integration' support for the flow as almost a 
third-party, bridging library. I think #1 makes the most sense, with the 
possibility that at some time it might even be broken out into its own 
build, although still in the same packages. This does imply that if Web 
Flow moves to the main source for 1.3, as expected, so will the portlet 
code.

Colin

-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

All,

We're preparing to integrate the Portlet support (contributed by J.Enrique 
Ruiz) into the Web Flow system. This brings up an interesting question: what 
packages should we use?

Should the SWF portlet support live in the SWF packages? For instance:
org.springframework.web.flow.action.portlet
org.springframework.web.flow.execution.portlet

Or should it live in the Spring Portlet MVC support:
org.springframework.web.portlet.flow

Any input on this would be much appreciated!
Keith and I are currently leaning towards option 1: put it in SWF.

Erwin Vervaet
erw...@er... 

I don't remember exactly why we put it in core... I think we didn't want to
encourage users to actually extend that class directly, but rather just let
it serve as base class for Spring's own exception classes - without
application code usually being aware of the base class.

Furthermore, NestedRuntimeException is designed to seamlessly appear like a
JDK 1.4 nested RuntimeException, mirroring the "getCause()" method etc. Once
we switch to JDK 1.4 being required, we should be able to simply drop our
NestedRuntimeException class and derive all of Spring's own exception
classes directly from RuntimeException.

I would argue that application code should - in general - either use
concrete Spring exceptions, JDK 1.4 exceptions or Commons Lang exceptions,
but not rely on Spring's own core NestedRuntimeException directly. For that
reason and for the sake of backwards compatibility, I'm not keen on moving
it to the util package.

Keith's closure, visitor and styler abstraction fit into the "core" package
anyway. Those are rather full-blown abstractions that exceed the scope of
the "util" package, which is just supposed to hold simple helper classes
(mainly static). Nevertheless, Keith's stuff is still below "beans" and co,
so "core" seems to be appropriate.

Juergen

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Monday, April 04, 2005 7:42 PM
To: spr...@li...
Subject: Re: [Springframework-developer] FW: package dependency

Agreed, although frankly in retrospect NestRuntimeException probably
belonged itself in util; it's incredibly useful for any environment
which doesn't want to force JDK 1.4+ requirements (since all Exceptions
can nest as of JDK 1.4, making the class superfluous).

Keith Donald wrote:

> Hey guys,
>
> Juergen and discussed this: a dependency on util -> core is NOT
> acceptable. “core” is intended for higher-level utilities used
> throughout Spring, for generic, more complete abstractions like the
> Resource API. It may depend on util, but not the other way around.
> Util is intended for low-level helpers, and should not depend on any
> other package but stuff in JDK 1.3. Both go in spring-core.jar.
>
> So in light of this, I’m relocating a good deal of packages from util
> to core, the closure, enums, comparator, and string styler support,
> respectively. This seems much better and solves the problem I was
> facing: that is, a class needing NestedRuntimeException, which is in
> the core.
>
> Keith
>
> ------------------------------------------------------------------------
>
> *From:* Keith Donald [mailto:ke...@in...]
> *Sent:* Sunday, April 03, 2005 8:30 PM
> *To:* 'spr...@li...'
> *Subject:* package dependency
>
> Is a package dependency from “util” to “core” acceptable? I could
> really use NestedRuntimeException there...
>
> Keith
>
> Keith Donald
>
> http://www.springframework.com <http://www.springframework.com/> -
> Spring Training, Consulting and Support - "From the Source"
>

--
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

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

We _could_ duplicate the class in util, and make the class in core a 
subclass. I don't know of how much value that would be at this point 
though, since all the code in Spring that throws it would still have to 
throw the old version, so APIs would not break. It would probably 
confuse things like crazy.

Colin

Erwin Vervaet wrote:

> NestedRuntimeException should really have been in util I guess, but 
> it's to late to change that...
> Erwin Vervaet
> erw...@er... <mailto:erw...@er...>
>
>     ----- Original Message -----
>     *From:* Keith Donald <mailto:ke...@in...>
>     *To:* spr...@li...
>     <mailto:spr...@li...>
>     *Sent:* Monday, April 04, 2005 6:48 PM
>     *Subject:* [Springframework-developer] FW: package dependency
>
>     Hey guys,
>
>     Juergen and discussed this: a dependency on util -> core is NOT
>     acceptable. “core” is intended for higher-level utilities used
>     throughout Spring, for generic, more complete abstractions like
>     the Resource API. It may depend on util, but not the other way
>     around. Util is intended for low-level helpers, and should not
>     depend on any other package but stuff in JDK 1.3. Both go in
>     spring-core.jar.
>
>     So in light of this, I’m relocating a good deal of packages from
>     util to core, the closure, enums, comparator, and string styler
>     support, respectively. This seems much better and solves the
>     problem I was facing: that is, a class needing
>     NestedRuntimeException, which is in the core.
>
>     Keith
>
>     ------------------------------------------------------------------------
>
>     *From:* Keith Donald [mailto:ke...@in...]
>     *Sent:* Sunday, April 03, 2005 8:30 PM
>     *To:* 'spr...@li...'
>     *Subject:* package dependency
>
>     Is a package dependency from “util” to “core” acceptable? I could
>     really use NestedRuntimeException there...
>
>     Keith
>
>     Keith Donald
>
>     http://www.springframework.com <http://www.springframework.com/> -
>     Spring Training, Consulting and Support - "From the Source"
>

-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

Agreed, although frankly in retrospect NestRuntimeException probably 
belonged itself in util; it's incredibly useful for any environment 
which doesn't want to force JDK 1.4+ requirements (since all Exceptions 
can nest as of JDK 1.4, making the class superfluous).

Keith Donald wrote:

> Hey guys,
>
> Juergen and discussed this: a dependency on util -> core is NOT 
> acceptable. “core” is intended for higher-level utilities used 
> throughout Spring, for generic, more complete abstractions like the 
> Resource API. It may depend on util, but not the other way around. 
> Util is intended for low-level helpers, and should not depend on any 
> other package but stuff in JDK 1.3. Both go in spring-core.jar.
>
> So in light of this, I’m relocating a good deal of packages from util 
> to core, the closure, enums, comparator, and string styler support, 
> respectively. This seems much better and solves the problem I was 
> facing: that is, a class needing NestedRuntimeException, which is in 
> the core.
>
> Keith
>
> ------------------------------------------------------------------------
>
> *From:* Keith Donald [mailto:ke...@in...]
> *Sent:* Sunday, April 03, 2005 8:30 PM
> *To:* 'spr...@li...'
> *Subject:* package dependency
>
> Is a package dependency from “util” to “core” acceptable? I could 
> really use NestedRuntimeException there...
>
> Keith
>
> Keith Donald
>
> http://www.springframework.com <http://www.springframework.com/> - 
> Spring Training, Consulting and Support - "From the Source"
>

-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

NestedRuntimeException should really have been in util I guess, but it's =
to late to change that...

Erwin Vervaet
erw...@er...
  ----- Original Message -----=20
  From: Keith Donald=20
  To: spr...@li...=20
  Sent: Monday, April 04, 2005 6:48 PM
  Subject: [Springframework-developer] FW: package dependency

  Hey guys,

  =20

  Juergen and discussed this: a dependency on util -> core is NOT =
acceptable.  "core" is intended for higher-level utilities used =
throughout Spring, for generic, more complete abstractions like the =
Resource API.  It may depend on util, but not the other way around.  =
Util is intended for low-level helpers, and should not depend on any =
other package but stuff in JDK 1.3.  Both go in spring-core.jar.

  =20

  So in light of this, I'm relocating a good deal of packages from util =
to core, the closure, enums, comparator, and string styler support, =
respectively.  This seems much better and solves the problem I was =
facing: that is, a class needing NestedRuntimeException, which is in the =
core.

  =20

  Keith

  =20

-------------------------------------------------------------------------=
-----

  From: Keith Donald [mailto:ke...@in...]=20
  Sent: Sunday, April 03, 2005 8:30 PM
  To: 'spr...@li...'
  Subject: package dependency

  =20

  Is a package dependency from "util" to "core" acceptable? I could =
really use NestedRuntimeException there...

  =20

  Keith

  =20

  Keith Donald

  http://www.springframework.com - Spring Training, Consulting and =
Support - "From the Source"

  =20

fyi

-----Original Message-----
From: J.Enrique Ruiz [mailto:er...@di...]=20
Sent: Monday, April 04, 2005 1:31 PM
To: Keith Donald
Cc: 'Erwin Vervaet'; C=E8sar Ordi=F1ana
Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
Feedback needed

Keith,

Saturday we saw your last work and immediately we updated our source =
code,
now integration is really simple. Today, we have updated the last =
changes
and we have refactored the portlet support code.

We have updated the package in:
http://opensource.atlassian.com/confluence/spring/display/WEBFLOW/Home

Note: To integrate portlet support, it is needed to include Portlet MVC
in spring-webflow-support.jar file. A way to do it is to add
<include name=3D"org/springframework/web/portlet/**"/> and
<include name=3D"org/springframework/web/servlet/**"/> to
webflow.support.jar target in the Spring build.xml file (line ~1351):

            ...
            <fileset dir=3D"${sandbox.target.classes.dir}">
                <include name=3D"META-INF/**"/>
                <include name=3D"org/springframework/binding/**"/>
                <include name=3D"org/springframework/util/**"/>
                <include name=3D"org/springframework/validation/**"/>
                <include name=3D"org/springframework/web/portlet/**"/>
                <include name=3D"org/springframework/web/servlet/**"/>
                <include name=3D"org/springframework/web/struts/**"/>
                <include name=3D"org/springframework/test/**"/>
            </fileset>
            ...

Regards.

>J.Enrique,
>
>Just wanted to let you know we're feeling pretty good/stable about the =
work
>we did this weekend on the FlowExecutionManager and =
FlowExecutionStorage
>strategies.  If you want, go ahead and update your Portlet code to =
bring it
>in-line with the recent refactoring (should be real easy now!), and =
we'll
>integrate it in for PR2.  Thanks, Keith
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On =
Behalf Of
>J. Enrique Ruiz
>Sent: Friday, April 01, 2005 3:26 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
>Feedback needed
>
>Hi all,
>
>We think it is a great idea that contributes to do SWF more independent =

>from
>the framework used, Portlets, Struts, etc.
>
>The biggest problem that we have encountered to use a unique=20
>FlowExecutionManager
>from Spring PortletMVC has been the manner to store/load the =
FlowExecution.
>
>With this new interface should be easy to implement an=20
>AbstractFlowExecutionManager, or a FlowExecutionManager that delegates =
on
>FlowExecutionStorage strategy (depends on the design pattern used).
>
>Regards.
> =20
>
--=20
J.Enrique Ruiz
Chief Research & Innovation Officer - DiSiD S.L.L. =
(http://www.disid.com)
Email: er...@di...

That mail was still hanging around in my Inbox, waiting to be processed :-)

Erwin Vervaet
erw...@er...
----- Original Message ----- 
From: "Steven Devijver" <ste...@gm...>
To: <spr...@li...>
Sent: Monday, April 04, 2005 10:39 AM
Subject: [Springframework-developer] Fwd: webflow & security

> Hi guys,
> 
> What are you views on the topics below?
> 
> Thanks
> 
> Steven
> 
> ---------- Forwarded message ----------
> From: Steven Devijver <ste...@gm...>
> Date: Mar 29, 2005 9:52 AM
> Subject: webflow & security
> To: spr...@li...
> 
> 
> Hi,
> 
> It would be nice if webflow would support J2EE roles on a state level.
> This way one could set a read-only role on all states except a save or
> delete state which would have a management role.
> 
> Next to that, ideally, it should be possible for the view technology
> to determine which buttons or anchors should or should not be rendered
> by checking the role of the current user with the role of the state
> linked to a given button or anchor.
> 
> Steven
> 
> --
> "If you want to be a different fish, you gotta jump out of the school."
> -- Captain Beefheart
> 
> 
> -- 
> "If you want to be a different fish, you gotta jump out of the school."
> -- Captain Beefheart
> 
> 
> -------------------------------------------------------
> 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
> 
>

Hey guys,

Juergen and discussed this: a dependency on util -> core is NOT acceptable.
"core" is intended for higher-level utilities used throughout Spring, for
generic, more complete abstractions like the Resource API.  It may depend on
util, but not the other way around.  Util is intended for low-level helpers,
and should not depend on any other package but stuff in JDK 1.3.  Both go in
spring-core.jar.

So in light of this, I'm relocating a good deal of packages from util to
core, the closure, enums, comparator, and string styler support,
respectively.  This seems much better and solves the problem I was facing:
that is, a class needing NestedRuntimeException, which is in the core.

Keith

  _____  

From: Keith Donald [mailto:ke...@in...] 
Sent: Sunday, April 03, 2005 8:30 PM
To: 'spr...@li...'
Subject: package dependency

Is a package dependency from "util" to "core" acceptable? I could really use
NestedRuntimeException there...

Keith

Keith Donald

http://www.springframework.com <http://www.springframework.com/>  - Spring
Training, Consulting and Support - "From the Source"

I think that a more generic pre-condition system needs to be included so 
that this kind of approach can be implemented in a simple manner.

Rob

Colin Sampaleanu wrote:

> This is assuming roles by themselves (as opposed to something like 
> ACLs) are even good enough as a basic concept for a significant 
> portion of the users.. I.e. do you really want to bake in something 
> like the idea of a String-based role?
>
> Steven Devijver wrote:
>
>> I agree J2EE specific code should be avoided. However, assigning one
>> or more roles to a state should be doable. How these roles are then
>> checked is a matter of implementation, J2EE being one option.
>>
>>
>> On Apr 4, 2005 4:47 PM, Colin Sampaleanu <col...@ex...> wrote:
>>  
>>
>>> Personally, I find J2EE container security completely useless (weak and
>>> pretty bad design) compared to something like Acegi Security. I'm not a
>>> very big fan of the idea of baking in J2EE security related code,
>>> although certainly it'd be good to structure the lib so that it's easy
>>> for users to add in either J2EE or Acegi Security related code.
>>>
>>> -- 
>>> Colin Sampaleanu
>>> Interface21 Principal Consultant
>>> Spring Training, Consulting and Support - "From the Source"
>>> http://www.springframework.com
>>>
>>>
>>> Steven Devijver wrote:
>>>
>>>   
>>>
>>>> Hi guys,
>>>>
>>>> What are you views on the topics below?
>>>>
>>>> Thanks
>>>>
>>>> Steven
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Steven Devijver <ste...@gm...>
>>>> Date: Mar 29, 2005 9:52 AM
>>>> Subject: webflow & security
>>>> To: spr...@li...
>>>>
>>>>
>>>> Hi,
>>>>
>>>> It would be nice if webflow would support J2EE roles on a state level.
>>>> This way one could set a read-only role on all states except a save or
>>>> delete state which would have a management role.
>>>>
>>>> Next to that, ideally, it should be possible for the view technology
>>>> to determine which buttons or anchors should or should not be rendered
>>>> by checking the role of the current user with the role of the state
>>>> linked to a given button or anchor.
>>>>
>>>> Steven
>>>>
>>>> -- 
>>>> "If you want to be a different fish, you gotta jump out of the 
>>>> school."
>>>> -- Captain Beefheart
>>>>     
>>>
>
>
> -------------------------------------------------------
> 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
>
>

Please forgive my ignorance. I believe configuring security
constraints on a state level is a useful feature. Instead of a string
based representation an object could be attached to a state which
could then be verified by a security manager with the user
authorizations and any other configuration.

On Apr 4, 2005 5:23 PM, Colin Sampaleanu <col...@ex...> wrote:
> This is assuming roles by themselves (as opposed to something like ACLs)
> are even good enough as a basic concept for a significant portion of the
> users.. I.e. do you really want to bake in something like the idea of a
> String-based role?
> 
> Steven Devijver wrote:
> 
> >I agree J2EE specific code should be avoided. However, assigning one
> >or more roles to a state should be doable. How these roles are then
> >checked is a matter of implementation, J2EE being one option.
> >
> >
> >On Apr 4, 2005 4:47 PM, Colin Sampaleanu <col...@ex...> wrote:
> >
> >
> >>Personally, I find J2EE container security completely useless (weak and
> >>pretty bad design) compared to something like Acegi Security. I'm not a
> >>very big fan of the idea of baking in J2EE security related code,
> >>although certainly it'd be good to structure the lib so that it's easy
> >>for users to add in either J2EE or Acegi Security related code.
> >>
> >>--
> >>Colin Sampaleanu
> >>Interface21 Principal Consultant
> >>Spring Training, Consulting and Support - "From the Source"
> >>http://www.springframework.com
> >>
> >>
> >>Steven Devijver wrote:
> >>
> >>
> >>
> >>>Hi guys,
> >>>
> >>>What are you views on the topics below?
> >>>
> >>>Thanks
> >>>
> >>>Steven
> >>>
> >>>---------- Forwarded message ----------
> >>>From: Steven Devijver <ste...@gm...>
> >>>Date: Mar 29, 2005 9:52 AM
> >>>Subject: webflow & security
> >>>To: spr...@li...
> >>>
> >>>
> >>>Hi,
> >>>
> >>>It would be nice if webflow would support J2EE roles on a state level.
> >>>This way one could set a read-only role on all states except a save or
> >>>delete state which would have a management role.
> >>>
> >>>Next to that, ideally, it should be possible for the view technology
> >>>to determine which buttons or anchors should or should not be rendered
> >>>by checking the role of the current user with the role of the state
> >>>linked to a given button or anchor.
> >>>
> >>>Steven
> >>>
> >>>--
> >>>"If you want to be a different fish, you gotta jump out of the school."
> >>>-- Captain Beefheart
> >>>
> >>>
> 
> -------------------------------------------------------
> 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
> 
> 

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

This is assuming roles by themselves (as opposed to something like ACLs) 
are even good enough as a basic concept for a significant portion of the 
users.. I.e. do you really want to bake in something like the idea of a 
String-based role?

Steven Devijver wrote:

>I agree J2EE specific code should be avoided. However, assigning one
>or more roles to a state should be doable. How these roles are then
>checked is a matter of implementation, J2EE being one option.
>
>
>On Apr 4, 2005 4:47 PM, Colin Sampaleanu <col...@ex...> wrote:
>  
>
>>Personally, I find J2EE container security completely useless (weak and
>>pretty bad design) compared to something like Acegi Security. I'm not a
>>very big fan of the idea of baking in J2EE security related code,
>>although certainly it'd be good to structure the lib so that it's easy
>>for users to add in either J2EE or Acegi Security related code.
>>
>>--
>>Colin Sampaleanu
>>Interface21 Principal Consultant
>>Spring Training, Consulting and Support - "From the Source"
>>http://www.springframework.com
>>
>>
>>Steven Devijver wrote:
>>
>>    
>>
>>>Hi guys,
>>>
>>>What are you views on the topics below?
>>>
>>>Thanks
>>>
>>>Steven
>>>
>>>---------- Forwarded message ----------
>>>From: Steven Devijver <ste...@gm...>
>>>Date: Mar 29, 2005 9:52 AM
>>>Subject: webflow & security
>>>To: spr...@li...
>>>
>>>
>>>Hi,
>>>
>>>It would be nice if webflow would support J2EE roles on a state level.
>>>This way one could set a read-only role on all states except a save or
>>>delete state which would have a management role.
>>>
>>>Next to that, ideally, it should be possible for the view technology
>>>to determine which buttons or anchors should or should not be rendered
>>>by checking the role of the current user with the role of the state
>>>linked to a given button or anchor.
>>>
>>>Steven
>>>
>>>--
>>>"If you want to be a different fish, you gotta jump out of the school."
>>>-- Captain Beefheart
>>>      
>>>

I agree J2EE specific code should be avoided. However, assigning one
or more roles to a state should be doable. How these roles are then
checked is a matter of implementation, J2EE being one option.

On Apr 4, 2005 4:47 PM, Colin Sampaleanu <col...@ex...> wrote:
> Personally, I find J2EE container security completely useless (weak and
> pretty bad design) compared to something like Acegi Security. I'm not a
> very big fan of the idea of baking in J2EE security related code,
> although certainly it'd be good to structure the lib so that it's easy
> for users to add in either J2EE or Acegi Security related code.
> 
> --
> Colin Sampaleanu
> Interface21 Principal Consultant
> Spring Training, Consulting and Support - "From the Source"
> http://www.springframework.com
> 
> 
> Steven Devijver wrote:
> 
> >Hi guys,
> >
> >What are you views on the topics below?
> >
> >Thanks
> >
> >Steven
> >
> >---------- Forwarded message ----------
> >From: Steven Devijver <ste...@gm...>
> >Date: Mar 29, 2005 9:52 AM
> >Subject: webflow & security
> >To: spr...@li...
> >
> >
> >Hi,
> >
> >It would be nice if webflow would support J2EE roles on a state level.
> >This way one could set a read-only role on all states except a save or
> >delete state which would have a management role.
> >
> >Next to that, ideally, it should be possible for the view technology
> >to determine which buttons or anchors should or should not be rendered
> >by checking the role of the current user with the role of the state
> >linked to a given button or anchor.
> >
> >Steven
> >
> >--
> >"If you want to be a different fish, you gotta jump out of the school."
> >-- Captain Beefheart
> >
> >
> >
> >
> 
> -------------------------------------------------------
> 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
> 
> 

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

Personally, I find J2EE container security completely useless (weak and 
pretty bad design) compared to something like Acegi Security. I'm not a 
very big fan of the idea of baking in J2EE security related code, 
although certainly it'd be good to structure the lib so that it's easy 
for users to add in either J2EE or Acegi Security related code.

-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

Steven Devijver wrote:

>Hi guys,
>
>What are you views on the topics below?
>
>Thanks
>
>Steven
>
>---------- Forwarded message ----------
>From: Steven Devijver <ste...@gm...>
>Date: Mar 29, 2005 9:52 AM
>Subject: webflow & security
>To: spr...@li...
>
>
>Hi,
>
>It would be nice if webflow would support J2EE roles on a state level.
>This way one could set a read-only role on all states except a save or
>delete state which would have a management role.
>
>Next to that, ideally, it should be possible for the view technology
>to determine which buttons or anchors should or should not be rendered
>by checking the role of the current user with the role of the state
>linked to a given button or anchor.
>
>Steven
>
>--
>"If you want to be a different fish, you gotta jump out of the school."
>-- Captain Beefheart
>
>
>  
>

Great. I will then check it into the sandbox...

Thierry TEMPLIER wrote:

>Dmitriy,
>
>I will clean it and send it to you...
>Thierry
>
> =20
>
>>Also, could this code become a part of the sandbox
>>for now?
>>
>>Dmitriy.
>>   =20
>>
>
>Take a look at my blog:
>http://templth.blogspot.com/
>
>
>=09
>
>=09
>	=09
>__________________________________________________________________
>D=E9couvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vo=
s mails !=20
>Cr=E9ez votre Yahoo! Mail sur http://fr.mail.yahoo.com/
>
>
>-------------------------------------------------------
>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=3D6595&alloc_id=3D14396&op=3Dclick
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> =20
>

2003	Jan	Feb (55)	Mar (100)	Apr (203)	May (330)	Jun (190)	Jul (302)	Aug (323)	Sep (197)	Oct (245)	Nov (490)	Dec (330)
2004	Jan (194)	Feb (400)	Mar (416)	Apr (415)	May (359)	Jun (381)	Jul (491)	Aug (311)	Sep (291)	Oct (273)	Nov (355)	Dec (266)
2005	Jan (306)	Feb (303)	Mar (520)	Apr (346)	May (255)	Jun (221)	Jul (171)	Aug (247)	Sep (147)	Oct (125)	Nov (165)	Dec (65)
2006	Jan (90)	Feb (53)	Mar (121)	Apr (103)	May (113)	Jun (103)	Jul (104)	Aug (67)	Sep (78)	Oct (82)	Nov (78)	Dec (70)
2007	Jan (77)	Feb (76)	Mar (63)	Apr (30)	May (47)	Jun (41)	Jul (44)	Aug (44)	Sep (49)	Oct (33)	Nov (25)	Dec (21)
2008	Jan (45)	Feb (13)	Mar (15)	Apr (12)	May (9)	Jun (33)	Jul (30)	Aug (7)	Sep (20)	Oct (17)	Nov (20)	Dec (10)
2009	Jan (8)	Feb (5)	Mar (12)	Apr (17)	May (19)	Jun (97)	Jul (77)	Aug (33)	Sep (24)	Oct (41)	Nov (16)	Dec (32)
2010	Jan (24)	Feb (14)	Mar (50)	Apr (71)	May (70)	Jun (64)	Jul (45)	Aug (62)	Sep (32)	Oct (4)	Nov (12)	Dec (2)
2011	Jan (1)	Feb (3)	Mar (4)	Apr (3)	May (6)	Jun (1)	Jul (4)	Aug (3)	Sep (4)	Oct (6)	Nov (3)	Dec (3)
2012	Jan (4)	Feb (8)	Mar (6)	Apr (10)	May (2)	Jun (3)	Jul (11)	Aug (10)	Sep (4)	Oct	Nov (1)	Dec (1)
2013	Jan (4)	Feb (1)	Mar (9)	Apr (1)	May (8)	Jun (2)	Jul (5)	Aug (2)	Sep	Oct (3)	Nov (10)	Dec (8)
2014	Jan (3)	Feb (12)	Mar (9)	Apr (12)	May (2)	Jun	Jul (3)	Aug (1)	Sep (1)	Oct (4)	Nov	Dec (2)
2015	Jan (1)	Feb (3)	Mar (4)	Apr (9)	May (2)	Jun (2)	Jul	Aug (2)	Sep (7)	Oct (9)	Nov (7)	Dec (9)
2016	Jan (7)	Feb (5)	Mar (5)	Apr (5)	May (8)	Jun (4)	Jul (5)	Aug (4)	Sep (6)	Oct (7)	Nov (2)	Dec (3)
2017	Jan (7)	Feb (8)	Mar (7)	Apr (3)	May (4)	Jun (3)	Jul (5)	Aug (8)	Sep (4)	Oct (2)	Nov (3)	Dec
2018	Jan	Feb	Mar	Apr (1)	May	Jun (1)	Jul	Aug	Sep	Oct	Nov (1)	Dec
2019	Jan	Feb (1)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (1)
2021	Jan	Feb (1)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2022	Jan	Feb (1)	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec
2024	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (1)	Dec
2025	Jan	Feb	Mar	Apr	May (1)	Jun	Jul (2)	Aug (5)	Sep (2)	Oct	Nov	Dec (1)
2026	Jan (1)	Feb	Mar (1)	Apr	May	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec

springframework-developer Mailing List for Spring Framework (Page 142)

springframework-developer — Spring Framework developers list