springframework-developer — Spring Framework developers list

[Springframework-developer] Re: [Acegisecurity-developer] Acegi Security's ContextHolder replaced by SecurityContext

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

Ben Alex wrote:

> Pursuant to Juergen's recommendation 
> (http://article.gmane.org/gmane.comp.java.springframework.devel/8290), 
> Acegi Security CVS has now had its ContextHolder and related classes 
> removed. This functionality has been replaced by SecurityContext, 
> which is an InheritableThreadLocal that provides a single 
> getter/setter pair for Authentication.
>
> This is a significant change for end users, but offers a number of 
> benefits:
>
> - Consistency with Spring core's use of a concrete ThreadLocal per 
> functional area
> - SecurityContext is strictly typed (which eliminates the need for 
> casting)
> - Simplified configuration as no need to specify a Context 
> implementation for HttpSessionContextIntegrationFilter
> - InheritableThreadLocal used instead of ThreadLocal to simplify rich 
> client usage (see http://forum.springframework.org/viewtopic.php?t=5004)
> - Elimination of handling the extra Context layer means less end user 
> code is required
>
> Unit tests pass and I've updated the upgrade-080-090.txt in some 
> detail. The reference guide has also been updated.
>
> It would be appreciated if developers could try the latest CVS with 
> their applications and report any difficulties. General feedback on 
> this change is also welcome.

As I read Juergen's suggestion, I thought he was just suggesting to go 
away from the ContextHolder with abitlity to hold a generic Context, as 
it is potentially confusing as to what is going to go in there. So he 
suggested a SecurityContextHolder which needs to hold a SecurityContext.

However, it seems to me that this simplification is much more than that, 
and may have gone too far, as it's all been collapsed into the one 
SecurityContext which is the threadlocal (effectively) and holds the 
Authentication. Unless I'm missing something it would still be of real 
use to have a real SecurityContextHolder which holds a pluggable 
SecurityContext. Then people can subclass that if needed to add extra 
data. The difference from before however is that now it is clearly 
security focused, and the lifecycle of the object is managed clearly by 
Acegi.

What does everybody think?

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

Re: [Springframework-developer] Acegi Security's ContextHolder replaced by SecurityContext

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

InheritableThreadLocal is a good idea for thread-bound context that should
actually be inherited. Hence, I've changed Spring's LocaleContextHolder to
use an InheritableThreadLocal.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Ben Alex
Sent: Saturday, May 07, 2005 11:17 AM
To: ace...@li...
Cc: spr...@li...
Subject: [Springframework-developer] Acegi Security's ContextHolder
replaced by SecurityContext


Pursuant to Juergen's recommendation
(http://article.gmane.org/gmane.comp.java.springframework.devel/8290),
Acegi Security CVS has now had its ContextHolder and related classes
removed. This functionality has been replaced by SecurityContext, which
is an InheritableThreadLocal that provides a single getter/setter pair
for Authentication.

This is a significant change for end users, but offers a number of benefits:

- Consistency with Spring core's use of a concrete ThreadLocal per
functional area
- SecurityContext is strictly typed (which eliminates the need for casting)
- Simplified configuration as no need to specify a Context
implementation for HttpSessionContextIntegrationFilter
- InheritableThreadLocal used instead of ThreadLocal to simplify rich
client usage (see http://forum.springframework.org/viewtopic.php?t=5004)
- Elimination of handling the extra Context layer means less end user
code is required

Unit tests pass and I've updated the upgrade-080-090.txt in some detail.
The reference guide has also been updated.

It would be appreciated if developers could try the latest CVS with
their applications and report any difficulties. General feedback on this
change is also welcome.

Cheers
Ben


-------------------------------------------------------
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=20
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Acegi Security's ContextHolder replaced by SecurityContext

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

Pursuant to Juergen's recommendation 
(http://article.gmane.org/gmane.comp.java.springframework.devel/8290), 
Acegi Security CVS has now had its ContextHolder and related classes 
removed. This functionality has been replaced by SecurityContext, which 
is an InheritableThreadLocal that provides a single getter/setter pair 
for Authentication.

This is a significant change for end users, but offers a number of benefits:

- Consistency with Spring core's use of a concrete ThreadLocal per 
functional area
- SecurityContext is strictly typed (which eliminates the need for casting)
- Simplified configuration as no need to specify a Context 
implementation for HttpSessionContextIntegrationFilter
- InheritableThreadLocal used instead of ThreadLocal to simplify rich 
client usage (see http://forum.springframework.org/viewtopic.php?t=5004)
- Elimination of handling the extra Context layer means less end user 
code is required

Unit tests pass and I've updated the upgrade-080-090.txt in some detail. 
The reference guide has also been updated.

It would be appreciated if developers could try the latest CVS with 
their applications and report any difficulties. General feedback on this 
change is also welcome.

Cheers
Ben

Re: [Springframework-developer] Re: Building WebFlow samples

[Keith D. <ke...@in...>]

Katentim,

I simplified the build.properties template in samples/webflow tonite.  I 
basically threw out all attempts at assuming users would have their paths to 
jar dependencies setup exactly like the spring-with-dependencies download, 
in favor of requiring explicit specification of such jars on a file-by-file 
basis.  It is indeed much simpler this way, what I was doing was a nice 
shot, but it was confusing I agree.

Anyway, let me know what you think of this:

# points to ant 1.6 build system for building samples
builds.dir=../../../builds

############################################################
# User-definable build properties neccessary to build samples.
# Ensure the approrpiate properties are set correctly for your environment.
#
# For a list of default properties, see the file:
#     ../../../builds/build.properties
#
# Note: you need to specify entries in this file for each required 
dependency for the
# sample you are building.
#
# For example, for Phonebook, you might set the following:
# 
commons.logging.jar=c:/mydevdir/lib/jakarta-commons/commons-logging-1.0.jar
#     jakarta.taglibs.jar=c:/mydevdir/lib/j2ee/jakarta-taglibs-1.1.jar
#     log4j.jar=c:/mydevdir/lib/log4j/log4j-1.2.9.jar
#     jstl.jar=c:/mydevdir/lib/jstl/jstl-1.1.jar
#     spring.jar=c:/mydevdir/lib/spring/spring-1.2.jar
#
# For the complete listing of the dependencies each sample app requires, see 
below or
# the 'build.webapp.libs' target in that sample's build.xml file.
############################################################

# Common dependencies to all samples - uncomment and specify the path for 
each dependency.
#commons.logging.jar=
#jakarta.taglibs.jar=
#jstl.jar=
#log4j.jar=
#spring.jar=

# Dependencies for the 'fileupload' sample - uncomment and specify if 
building
#commons.fileupload.jar=

# Dependencies for the 'birthdate' sample - uncomment and specify if 
building
#commons.beanutils.jar=
#commons.collections.jar=
#commons.digester.jar=
#commons.validator.jar=
#jakarta.oro.jar=
#struts.jar=

# Dependencies for the 'sellitem' sample - uncomment and specify if building
#commons.codec.jar=
#ognl.jar=

# location of spring webflow jars (boilerplate)
spring.webflow.jar=../../../dist/spring-webflow.jar
spring.webflow.support.jar=../../../dist/spring-webflow-support.jar

# location of tomcat - uncomment and specify for automated sample app 
deployment
#tomcat.dir=

Thanks,
Keith

----- Original Message ----- 
From: "Keith Donald" <ke...@in...>
To: <spr...@li...>
Sent: Thursday, May 05, 2005 11:02 PM
Subject: Re: [Springframework-developer] Re: Building WebFlow samples


Well, as stated, if building from CVS none of that 'tweaking' is required.

Such teaking of properties is only neccessary if people are attempting to
build the samples direct from an expanded spring-webflow preview release
archive.  In that case, since we don't ship any dependencies with the
webflow releases, you have to be able to point to a valid spring.jar, and
valid locations to the other jars as well...

In general, I've tried to make it as simple as possible here, where the
build system assumes, by default, the users stores all their jars
consistently under a devtools.lib.dir, so they don't have to manually
specify the location of each dependent .jar.

I'll see what I can do to make this more explicit, as our goal here is to
make it as easy as possible to build the samples.

Keith

> It's step 3, "tweak the copied 'build.properties'" that isn't straight
> forward (it's important to get people up and running ASAP). The entry:
>
> # location where development tools reside (e.g apps, libs, templates,
> etc.)
> devtools.dir=c:/development/devtools
>
> ...leaves you scratching your head and reading through the build files
> to see where they should point to. While we should leave the property
> names as is (unless you do a complete refactor), how about some better
> default values and descriptions. E.g.
>
> # location of spring root directory
> devtools.dir=c:/java/spring-framework-1.2-rc2
>
> # location where spring lib dependencies reside
> devtools.lib.dir=${devtools.dir}/lib
>
> # location of spring.jar
> spring.dir=${devtools.dir}/dist
>
> ... or am I on the wrong track? I'd presume everyone would organise
> their java library directories differently, so a reference to a spring
> root directory is the essential property (again maybe a refactor of
> property names is required). What do you think?
>
> Finally, you could just combine all the Ant commands required to:
> 1. build alljars webflow.jar webflow.support.jar
>
> ...which is still quite readable, and less steps.
>
> PS. My problem below was missing the webflow.support.jar. Thanks for the
>    help.
>
> Keith Donald wrote:
>> I updated the readme.txt instructions.  Please let me know if these
>> could
>> still be improved.
>>
>> /*
>>  * webflow-samples
>>  *
>>  * phonebook - central sample demonstrating most webflow features
>>  * itemlist - demonstrates application transaction tokens and expired
>> flow
>> cleanup
>>  * fileupload - demonstrates multipart file upload with webflow
>>  * birthdate - demonstrates Struts integration and the MultiAction
>>  * sellitem - demonstrates a wizard with conditional transitions and
>> continuations
>>  *
>>  * @author Keith Donald
>>  * @since Mar 2005
>>  * @version $Id: readme.txt,v 1.2 2005/04/11 06:19:53 kdonald Exp $
>>  */
>>
>> HOW TO BUILD WEBFLOW SAMPLES - FROM RELEASED DISTRIBUTION
>>
>> 1. copy in the template 'build.properties' file in the same directory as
>> this file to the root directory of the sample you wish to run.
>>
>> 2. cd to the root directory of the sample you wish to run.
>>
>> 3. tweak the copied 'build.properties' to your environment
>>
>> 4. tweak 'build.bat' to point your environemnt so the ant build system
>> can
>> execute.
>>
>> 5. run 'build dist' to build the application .war file, ready for
>> deployment.
>>
>> 6. if tomcat is installed on your system, run 'build
>> tomcat.server.start' to
>> start it and deploy the
>> sample application in one step.
>>
>> 7. access the sample at the appropriate URL, e.g
>> http://localhost:8080/phonebook
>>
>> HOW TO BUILD WEBFLOW SAMPLES - FROM CVS
>>
>> From the spring root directory, execute from the command line:
>>
>> 1. build alljars
>>
>> 2. build webflow.jar
>>
>> 3. build webflow.support.jar
>>
>> 4. Proceed with the RELEASED DISTRIBUTION instructions above,
>> customizing
>> your local build.properties for each sample as necessary.  Note: If all
>> want
>> to do is build the sample .war file for manual deployment, you shouldn't
>> have to do any build.properties customization--the default properties
>> will
>> suffice.  Property customization is only necessary if you have custom
>> paths
>> to dependent jar files or wish to automate deployment with a local
>> tomcat
>> installation.
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On Behalf
>> Of
>> kat...@ho...
>> Sent: Thursday, May 05, 2005 1:04 AM
>> To: spr...@li...
>> Subject: [Springframework-developer] Building WebFlow samples
>>
>> I was building the phonebook sample and found it wouldn't compile as the
>> sandbox classes were missing. How is everyone else obtaining/generating
>> the samples?
>>
>> I added a patch (see below) which fixes the problem - but there may be
>> another approach. What are other doing? :)
>>
>> If there is a better way, maybe we can improve the build instructions in
>> the distro.
>>
>> Cheers.
>>
>>
>> Compiling 9 source files to
>> C:\work\spring\samples\webflow\phonebook\target\classes
>> C:\work\spring\samples\webflow\phonebook\src\org\springframework\samples\pho
>> nebook\web\flow\PersonDetailFlowBuilder.java:18:
>> package org.springframework.binding.convert does not exist
>> import org.springframework.binding.convert.ConversionExecutor;
>>
>>
>> ===================================================================
>> RCS file: /cvsroot/springframework/spring/builds/build.xml,v
>> retrieving revision 1.2
>> diff -u -r1.2 build.xml
>> --- build.xml 27 Apr 2005 00:14:44 -0000 1.2
>> +++ build.xml 5 May 2005 04:44:26 -0000
>> @@ -15,6 +15,7 @@
>>   <pathelement location="${target.classes.dir}" />
>>   <pathelement location="${commons.logging.jar}" />
>>   <pathelement location="${spring.jar}" />
>> + <pathelement location="${spring.sandbox.jar}" />
>>   <pathelement location="${spring.mock.jar}" />
>>   </path>
>>
>>
>>
>> -------------------------------------------------------
>> 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=20
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> 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=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=20
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>


-- 
Keith Donald
Principal Consultant, Interface21
http://www.springframework.com - Spring Services From the Source


-------------------------------------------------------
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=20
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring 1.2 RC2 and Acegi Security

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

Juergen Hoeller wrote:

>Colin,
>
>  
>
>>>I'm not sure whether we should keep the class-based delegate lookup. If we
>>>do, I would introduce a "targetBeanClass" property, with a strict check -
>>>      
>>>
>if
>  
>
>>>there isn't exactly one matching bean in the context, we'll fail. However,
>>>      
>>>
>I
>  
>
>>>prefer lookup by bean name, in particular if we simply use the filter name
>>>as target bean name.
>>>      
>>>
>>I would keep it if it doesn't get in the way of the bean name default
>>strategy (which it doesn't seem to), as it's potentially useful to some
>>people.
>>    
>>
>
>I rather see it like this: If there is no compelling use case for specifying
>the fully qualified class name of the target filter instead of the bean name
>there, I'd like to only provide the option to specify the target bean name
>(which makes the interaction easier to track and results in shorter
>configuration).
>  
>
Well, I think the class name has some value for part of the same reason 
byType matching exists in the context. I mean it's not autowired in this 
casse, but it's still a simpler config sometimes. If you know there 
should be exactly one filter of that type (which is usually the case for 
most filters), then you can just put the classname. And if you ever 
refactor, the IDE will take care of fixing the name, etc. I'm not 
incredibly hung up on this, but it probably provides some value.

>  
>
>>>Regarding the lifecycle concerns: init and destroy should probably always
>>>      
>>>
>be
>  
>
>>>delegated to the target Filter bean instance. If the target Filter uses
>>>      
>>>
>bean
>  
>
>>>lifecycle callbacks, it's gonna implement Filter.init/destroy as empty
>>>anyway. So I guess we don't really need an explicit config setting for
>>>      
>>>
>this.
>  
>
>>I'm not sure I agree about this. If the methods are always delegated,
>>then it somewhat precludes for example somebody subclassign an existing
>>filter to try to use that codebase as-is. If the init/destroy doesn't
>>happen by default, then the filter class in question can decide when/if
>>to call the Filter interface lifecycle methods...
>>    
>>
>
>I'm not sure if I understand that use case. Subclassing a Filter is
>certainly possible, and if someone defines a DelegatingFilterProxy for that
>class, I would expect the Filter lifecycle to always be called there, as the
>target *is* a Filter. If someone wants to suppress those Filter.init/destroy
>calls, there's always the option to override those methods with empty
>implementations.
>
>Alternatively, any existing Filter can be held as a delegate within some
>wrapper class, whether exposing the Filter interface or not. That allows to
>have full control over the lifecycle, only calling stuff on the delegate
>that you really want to call. I consider this preferable to subclassing an
>existing Filter if you don't want to inherit the existing Filter's lifecycle
>behavior.
>  
>
I guess my main objection is that it just seems weird to be calling 
lifecycle methods you know don't do anything (or shouldn't do anything), 
if you know Spring is really managing the lifecycle. But I guess it 
doesn't hurt. This also means you can't make the Filter interface 
destroy() method the bean destroy method called by the bean container 
(since it would be called twice), but I guess that's not that big a deal.


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

[Springframework-developer] spring Build Failed

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

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

Re: [Springframework-developer] New www.springframework.org site is live!

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

On Fri, 2005-05-06 at 11:53 -0400, Colin Sampaleanu wrote:

> You certainly _can_ get ssh access into the new host, although that=20
> doesn't get it into the CMS anyway. So if it stays as static HTML=20
> content, I'm not so sure it necessarilly adds much value to push the=20
> stuff to the new host.

actually it's a couple of PHP pages that read in the build results and
generate the pages.  I'll convert the pages to the new L&F at some point
then and leave them on the SF servers.


--=20
Darren Davison
Public Key: 0xDD356B0D

Re: [Springframework-developer] New www.springframework.org site is live!

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

Darren Davison wrote:

>On Fri, May 6, 2005 7:32, Erwin Vervaet said:
>
>  
>
>>* If you click "Development > Continuous Build" you go to a somewhat messed
>>up page that has the old look & feel.
>>    
>>
>
>the continuous build page is on the SF project web servers as I never had SSH
>(or FTP) access to the springframework.org site.  Materials from the compile
>farm are transferred from there to my home server then up to the web server.
>
>I can either replicate the new look and feel on the project web space at SF or
>transfer the material up to the new servers if preferred.
>
>  
>
You certainly _can_ get ssh access into the new host, although that 
doesn't get it into the CMS anyway. So if it stays as static HTML 
content, I'm not so sure it necessarilly adds much value to push the 
stuff to the new host. The builds are on SF anyway, and keeping the data 
there means there's means the page can probably be updated more easily, 
and there's reduced bandwidth usage on the new host as people will 
access the data from SF instead...



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

Re: [Springframework-developer] New www.springframework.org site is live!

[yanger1997 <yan...@ya...>]

You lost spring Chinese forum link.^_^
http://spring.jactiongroup.net

Yanger

Colin Sampaleanu wrote:

> Erwin Vervaet wrote:
>
>> Just a couple of remarks/questions:
>>
>> * Where are all the links to articles and presentations? The articles 
>> page only lists 2 articles. If I remember correctly there used to be 
>> quite a bit more. Also, the presentations page is just "page not found".
>
>
> The old site is still temporarilly available at
>   http://oldwww.springframework.org.
>
> There were not that many articles. The old site was completely static 
> and maintained by hand, with some stuff being moved off the front page 
> when it got older, mainly news and events. The demo/tutorial stuff is 
> not on the new site yet, that's one thing I can think of.
>
> The basic idea with technical articles and presentations is that 
> people enter a 'story' as the content type, and assign it the 
> "Techincal Article" or "Presentation" category. Then it gets 
> aggregated automatically. We can of course also have a static page for 
> anything that we want, so it may make sense to have static articles 
> and presentation pages, for more important links, and then also have 
> the auto-aggregated page.
>
>> * The submenu under the "links" menu does not reflect the structure. 
>> It only lists "Buttons", but not "Articles" or "Presentations".
>>
>> * If you click "Development > Continuous Build" you go to a somewhat 
>> messed up page that has the old look & feel.
>
>
> Will reply to Darren's other message.
>
>>
>> * When you click "Documentation > Books" the menu on the left collapses.
>
>
> This is normal. What you are looking at here is an aggregation page. 
> The contents just get selected based on the category they have.
>
>>
>> * "Documentation > PDF Manual" gives "page not found".
>
>
> fixed
>
>>
>> * "About > License" does not link to the license.
>
>
> This was intentional, to the extent that this is the only page on 
> _our_ site that talks about the Spring license. I did want a link on 
> the menu at left for the License, since it's important to a lot of 
> people, and it's hI guess that link could take you directly to the 
> Apache License at Apache. But to me it's a little bit diferent to have 
> a menu link called License (which you do want as it's highly visible) 
> and have that take you to a page which says on it that the license is 
> Apache, then points you to that, than to have that menu like take you 
> directly to the Apache license. The latter action implies something, 
> but doesn't say it.
>
>>
>> * IMHO the font size is a bit on the large side for the "main content 
>> area".
>
>
> This is quite debateable. FirFox/Mozilla can always scale any fonts, 
> but on the other hand if you want people in IE to be able to scale 
> fonts up or down, you have to make fonts be relative, not using fixed 
> pixel sizes. This is how the site is set up now. But in fact if you do 
> that, fonts in FireFox/Mozilla are actually going to look pretty much 
> smaller. As it is, on the 3 systems I've tried the site on, IE looks 
> pretty normal (maybe the headline font for each article could be 
> smaller), but FireFox/Mozilla looks pretty tiny, and for sure needs to 
> be _bigger_. I don't consider the latter that big a deal, as 
> FireFox/Mozilla users are pretty used to scaling stuff as needed. We 
> could actually get the site to look identical in both browsers by 
> using pixel fonts, but then IE users  would lose the ability to scale 
> to a size they need.
>
>

Re: [Springframework-developer] New www.springframework.org site is live!

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

Erwin Vervaet wrote:

> Just a couple of remarks/questions:
>
> * Where are all the links to articles and presentations? The articles 
> page only lists 2 articles. If I remember correctly there used to be 
> quite a bit more. Also, the presentations page is just "page not found".

The old site is still temporarilly available at
   http://oldwww.springframework.org.

There were not that many articles. The old site was completely static 
and maintained by hand, with some stuff being moved off the front page 
when it got older, mainly news and events. The demo/tutorial stuff is 
not on the new site yet, that's one thing I can think of.

The basic idea with technical articles and presentations is that people 
enter a 'story' as the content type, and assign it the "Techincal 
Article" or "Presentation" category. Then it gets aggregated 
automatically. We can of course also have a static page for anything 
that we want, so it may make sense to have static articles and 
presentation pages, for more important links, and then also have the 
auto-aggregated page.

> * The submenu under the "links" menu does not reflect the structure. 
> It only lists "Buttons", but not "Articles" or "Presentations".
>
> * If you click "Development > Continuous Build" you go to a somewhat 
> messed up page that has the old look & feel.

Will reply to Darren's other message.

>
> * When you click "Documentation > Books" the menu on the left collapses.

This is normal. What you are looking at here is an aggregation page. The 
contents just get selected based on the category they have.

>
> * "Documentation > PDF Manual" gives "page not found".

fixed

>
> * "About > License" does not link to the license.

This was intentional, to the extent that this is the only page on _our_ 
site that talks about the Spring license. I did want a link on the menu 
at left for the License, since it's important to a lot of people, and 
it's hI guess that link could take you directly to the Apache License at 
Apache. But to me it's a little bit diferent to have a menu link called 
License (which you do want as it's highly visible) and have that take 
you to a page which says on it that the license is Apache, then points 
you to that, than to have that menu like take you directly to the Apache 
license. The latter action implies something, but doesn't say it.

>
> * IMHO the font size is a bit on the large side for the "main content 
> area".

This is quite debateable. FirFox/Mozilla can always scale any fonts, but 
on the other hand if you want people in IE to be able to scale fonts up 
or down, you have to make fonts be relative, not using fixed pixel 
sizes. This is how the site is set up now. But in fact if you do that, 
fonts in FireFox/Mozilla are actually going to look pretty much smaller. 
As it is, on the 3 systems I've tried the site on, IE looks pretty 
normal (maybe the headline font for each article could be smaller), but 
FireFox/Mozilla looks pretty tiny, and for sure needs to be _bigger_. I 
don't consider the latter that big a deal, as FireFox/Mozilla users are 
pretty used to scaling stuff as needed. We could actually get the site 
to look identical in both browsers by using pixel fonts, but then IE 
users  would lose the ability to scale to a size they need.


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

Re: [Springframework-developer] New www.springframework.org site is live!

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

Darren Davison wrote:

>On Fri, May 6, 2005 7:32, Erwin Vervaet said:
>
>  
>
>>* If you click "Development > Continuous Build" you go to a somewhat messed
>>up page that has the old look & feel.
>>    
>>
>
>another point just noticed: the Development > Mailing List href points to the
>Development page so you don't go anywhere.
>
>
>  
>
That was intentional. Just to draw attention to the mailing list, which 
is mentioned on that page. But it might make more sense to just point 
that link to the list page at SF, I agree.


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

Re: [Springframework-developer] New www.springframework.org site is live!

[yanger1997 <yan...@ya...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Congratulation.<br>
<br>
<br>
Darren Davison wrote:
<blockquote
 cite="mid...@ba..."
 type="cite">
  <pre wrap="">On Fri, May 6, 2005 7:32, Erwin Vervaet said:

  </pre>
  <blockquote type="cite">
    <pre wrap="">* If you click "Development &gt; Continuous Build" you go to a somewhat messed
up page that has the old look &amp; feel.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
the continuous build page is on the SF project web servers as I never had SSH
(or FTP) access to the springframework.org site.  Materials from the compile
farm are transferred from there to my home server then up to the web server.

I can either replicate the new look and feel on the project web space at SF or
transfer the material up to the new servers if preferred.

  </pre>
</blockquote>
</body>
</html>

Re: [Springframework-developer] Spring 1.2 RC2 and Acegi Security

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

Colin,

>>I'm not sure whether we should keep the class-based delegate lookup. If we
>>do, I would introduce a "targetBeanClass" property, with a strict check -
if
>>there isn't exactly one matching bean in the context, we'll fail. However,
I
>>prefer lookup by bean name, in particular if we simply use the filter name
>>as target bean name.
>
> I would keep it if it doesn't get in the way of the bean name default
> strategy (which it doesn't seem to), as it's potentially useful to some
> people.

I rather see it like this: If there is no compelling use case for specifying
the fully qualified class name of the target filter instead of the bean name
there, I'd like to only provide the option to specify the target bean name
(which makes the interaction easier to track and results in shorter
configuration).

>>Regarding the lifecycle concerns: init and destroy should probably always
be
>>delegated to the target Filter bean instance. If the target Filter uses
bean
>>lifecycle callbacks, it's gonna implement Filter.init/destroy as empty
>>anyway. So I guess we don't really need an explicit config setting for
this.
>
> I'm not sure I agree about this. If the methods are always delegated,
> then it somewhat precludes for example somebody subclassign an existing
> filter to try to use that codebase as-is. If the init/destroy doesn't
> happen by default, then the filter class in question can decide when/if
> to call the Filter interface lifecycle methods...

I'm not sure if I understand that use case. Subclassing a Filter is
certainly possible, and if someone defines a DelegatingFilterProxy for that
class, I would expect the Filter lifecycle to always be called there, as the
target *is* a Filter. If someone wants to suppress those Filter.init/destroy
calls, there's always the option to override those methods with empty
implementations.

Alternatively, any existing Filter can be held as a delegate within some
wrapper class, whether exposing the Filter interface or not. That allows to
have full control over the lifecycle, only calling stuff on the delegate
that you really want to call. I consider this preferable to subclassing an
existing Filter if you don't want to inherit the existing Filter's lifecycle
behavior.

Juergen

Re: [Springframework-developer] TopLink support

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

The issues with PetClinic's HSQLPlatform have been resolved yesterday, so
everything should work nicely out-of-the-box now. Anybody who has some time
and motivation to play with this, please do so :-)

After some refinements yesterday, our TopLink support and PetClinic's
TopLink layer should work properly with both TopLink 9.0.4 and 10.1.3 (the
latter currently being a "developer release"). I would actually recommend
downloading TopLink 10.1.3, as it is just a 13 MB zip download (in contrast
to the "Oracle Universal Installer" download for 9.0.4, which has 130 MB!!).

All you need to do to make PetClinic work on TopLink is drop a full
toplink.jar plus xmlparserv2.jar (from the TopLink distribution) into
"lib/toplink" before building or "WEB-INF/lib" after building PetClinic.
Then comment in "applicationContext-toplink.xml" in web.xml, and off you go
:-)

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Juergen Hoeller
Sent: Wednesday, May 04, 2005 3:58 PM
To: spr...@li...
Subject: [Springframework-developer] TopLink support


Hi everybody,

In case you've been wondering what I was working on so busily... we now have
fully integrated TopLink support in our CVS, including a TopLink
implementation of PetClinic's persistence layer :-) Many thanks to Jim Clark
from Oracle who implemented the original version, and of course to Oracle
for granting the submission!

It's modeled somewhat analogously to our Hibernate support, although with
the important difference that we use a custom SessionFactory interface for
TopLink (because TopLink does not define such a resource out of the box).
There are the usual suspects: LocalSessionFactoryBean, TopLinkTemplate,
TopLinkCallback, TopLinkTransactionManager.

I've documented the TopLink data access operations quite extensively,
because the semantics are significantly different from Hibernate's. For
example, TopLink uses a shared object cache as second-level cache, in
contrast to Hibernate and JDO which only hold flat data there. This leads to
some very important differences in the lifecycle of persistent objects.

An important distinction is between working with a TopLink Session
(read-only) and working with a TopLink UnitOfWork (write operations). Of
course, our TopLink support allows for both in callback style. The
convenience operations defined on TopLinkTemplate allow for working with
both too, either implicitly determined through the current transaction
status or explicitly determined through a "enforceReadOnly" argument.

Notably, there is *no* OpenSessionInViewFilter or
OpenSessionInViewInterceptor for TopLink: it is simply not necessary.
TopLink will automatically apply appropriate lazy loading, whether within an
active Session or outside of it.

Aside from the deployment-ready TopLink persistence layer, the "petclinic"
directory also contains the TopLink Mapping Workbench project that the
mapping XML file was created with. You can simply open the project file in
with any TopLink Mapping Workbench implementation and have a visual few on
the mappings.

For licensing reasons, we only ship a toplink-api.jar that we can compile
against. To run the PetClinic web application or its test suite, a full
toplink.jar and xmlparserv2.jar (both from the TopLink distribution) need to
be dropped into the "lib/toplink" directory (or the deployed "WEB-INF/lib"
directory).

Finally, PetClinic's TopLink layer is currently not able to properly insert
objects, due to TopLink's default HSQLPlatform implementation: we need a
special subclass of this to leverage HSQLDB's identity columns. Such a
subclass is already committed but not fully active yet, simply because we
need some additional methods exposed in our toplink-api.jar to be able to
compile it. This should be resolved by tonight; everything else should
already work!

Juergen



-------------------------------------------------------
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=20
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] (bez =?ISO-8859-2?Q?p=F8edm=ECtu=29?=

[<pe...@ja...>]

Re: [Springframework-developer] New www.springframework.org site is live!

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

On Fri, May 6, 2005 7:32, Erwin Vervaet said:

> * If you click "Development > Continuous Build" you go to a somewhat me=
ssed
> up page that has the old look & feel.

another point just noticed: the Development > Mailing List href points to=
 the
Development page so you don't go anywhere.


--=20
Darren Davison
Public Key: 0xDD356B0D

Re: [Springframework-developer] New www.springframework.org site is live!

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

On Fri, May 6, 2005 7:32, Erwin Vervaet said:

> * If you click "Development > Continuous Build" you go to a somewhat me=
ssed
> up page that has the old look & feel.

the continuous build page is on the SF project web servers as I never had=
 SSH
(or FTP) access to the springframework.org site.  Materials from the comp=
ile
farm are transferred from there to my home server then up to the web serv=
er.

I can either replicate the new look and feel on the project web space at =
SF or
transfer the material up to the new servers if preferred.

--=20
Darren Davison
Public Key: 0xDD356B0D

Re: [Springframework-developer] New www.springframework.org site is live!

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

Just a couple of remarks/questions:

* Where are all the links to articles and presentations? The articles page 
only lists 2 articles. If I remember correctly there used to be quite a bit 
more. Also, the presentations page is just "page not found".

* The submenu under the "links" menu does not reflect the structure. It only 
lists "Buttons", but not "Articles" or "Presentations".

* If you click "Development > Continuous Build" you go to a somewhat messed 
up page that has the old look & feel.

* When you click "Documentation > Books" the menu on the left collapses.

* "Documentation > PDF Manual" gives "page not found".

* "About > License" does not link to the license.

* IMHO the font size is a bit on the large side for the "main content area".

Erwin 

Re: [Springframework-developer] Re: Building WebFlow samples

[Keith D. <ke...@in...>]

Well, as stated, if building from CVS none of that 'tweaking' is required.

Such teaking of properties is only neccessary if people are attempting to
build the samples direct from an expanded spring-webflow preview release
archive.  In that case, since we don't ship any dependencies with the
webflow releases, you have to be able to point to a valid spring.jar, and
valid locations to the other jars as well...

In general, I've tried to make it as simple as possible here, where the
build system assumes, by default, the users stores all their jars
consistently under a devtools.lib.dir, so they don't have to manually
specify the location of each dependent .jar.

I'll see what I can do to make this more explicit, as our goal here is to
make it as easy as possible to build the samples.

Keith

> It's step 3, "tweak the copied 'build.properties'" that isn't straight
> forward (it's important to get people up and running ASAP). The entry:
>
> # location where development tools reside (e.g apps, libs, templates,
> etc.)
> devtools.dir=c:/development/devtools
>
> ...leaves you scratching your head and reading through the build files
> to see where they should point to. While we should leave the property
> names as is (unless you do a complete refactor), how about some better
> default values and descriptions. E.g.
>
> # location of spring root directory
> devtools.dir=c:/java/spring-framework-1.2-rc2
>
> # location where spring lib dependencies reside
> devtools.lib.dir=${devtools.dir}/lib
>
> # location of spring.jar
> spring.dir=${devtools.dir}/dist
>
> ... or am I on the wrong track? I'd presume everyone would organise
> their java library directories differently, so a reference to a spring
> root directory is the essential property (again maybe a refactor of
> property names is required). What do you think?
>
> Finally, you could just combine all the Ant commands required to:
> 1. build alljars webflow.jar webflow.support.jar
>
> ...which is still quite readable, and less steps.
>
> PS. My problem below was missing the webflow.support.jar. Thanks for the
>    help.
>
> Keith Donald wrote:
>> I updated the readme.txt instructions.  Please let me know if these
>> could
>> still be improved.
>>
>> /*
>>  * webflow-samples
>>  *
>>  * phonebook - central sample demonstrating most webflow features
>>  * itemlist - demonstrates application transaction tokens and expired
>> flow
>> cleanup
>>  * fileupload - demonstrates multipart file upload with webflow
>>  * birthdate - demonstrates Struts integration and the MultiAction
>>  * sellitem - demonstrates a wizard with conditional transitions and
>> continuations
>>  *
>>  * @author Keith Donald
>>  * @since Mar 2005
>>  * @version $Id: readme.txt,v 1.2 2005/04/11 06:19:53 kdonald Exp $
>>  */
>>
>> HOW TO BUILD WEBFLOW SAMPLES - FROM RELEASED DISTRIBUTION
>>
>> 1. copy in the template 'build.properties' file in the same directory as
>> this file to the root directory of the sample you wish to run.
>>
>> 2. cd to the root directory of the sample you wish to run.
>>
>> 3. tweak the copied 'build.properties' to your environment
>>
>> 4. tweak 'build.bat' to point your environemnt so the ant build system
>> can
>> execute.
>>
>> 5. run 'build dist' to build the application .war file, ready for
>> deployment.
>>
>> 6. if tomcat is installed on your system, run 'build
>> tomcat.server.start' to
>> start it and deploy the
>> sample application in one step.
>>
>> 7. access the sample at the appropriate URL, e.g
>> http://localhost:8080/phonebook
>>
>> HOW TO BUILD WEBFLOW SAMPLES - FROM CVS
>>
>> From the spring root directory, execute from the command line:
>>
>> 1. build alljars
>>
>> 2. build webflow.jar
>>
>> 3. build webflow.support.jar
>>
>> 4. Proceed with the RELEASED DISTRIBUTION instructions above,
>> customizing
>> your local build.properties for each sample as necessary.  Note: If all
>> want
>> to do is build the sample .war file for manual deployment, you shouldn't
>> have to do any build.properties customization--the default properties
>> will
>> suffice.  Property customization is only necessary if you have custom
>> paths
>> to dependent jar files or wish to automate deployment with a local
>> tomcat
>> installation.
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On Behalf
>> Of
>> kat...@ho...
>> Sent: Thursday, May 05, 2005 1:04 AM
>> To: spr...@li...
>> Subject: [Springframework-developer] Building WebFlow samples
>>
>> I was building the phonebook sample and found it wouldn't compile as the
>> sandbox classes were missing. How is everyone else obtaining/generating
>> the samples?
>>
>> I added a patch (see below) which fixes the problem - but there may be
>> another approach. What are other doing? :)
>>
>> If there is a better way, maybe we can improve the build instructions in
>> the distro.
>>
>> Cheers.
>>
>>
>> Compiling 9 source files to
>> C:\work\spring\samples\webflow\phonebook\target\classes
>> C:\work\spring\samples\webflow\phonebook\src\org\springframework\samples\pho
>> nebook\web\flow\PersonDetailFlowBuilder.java:18:
>> package org.springframework.binding.convert does not exist
>> import org.springframework.binding.convert.ConversionExecutor;
>>
>>
>> ===================================================================
>> RCS file: /cvsroot/springframework/spring/builds/build.xml,v
>> retrieving revision 1.2
>> diff -u -r1.2 build.xml
>> --- build.xml	27 Apr 2005 00:14:44 -0000	1.2
>> +++ build.xml	5 May 2005 04:44:26 -0000
>> @@ -15,6 +15,7 @@
>>   		<pathelement location="${target.classes.dir}" />
>>   		<pathelement location="${commons.logging.jar}" />
>>   		<pathelement location="${spring.jar}" />
>> +		<pathelement location="${spring.sandbox.jar}" />
>>   		<pathelement location="${spring.mock.jar}" />
>>   	</path>
>>
>>
>>
>> -------------------------------------------------------
>> 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=20
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> 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=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=20
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>


-- 
Keith Donald
Principal Consultant, Interface21
http://www.springframework.com - Spring Services From the Source

Re: [Springframework-developer] New www.springframework.org site is live!

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

I somehow forgot to mention and thank Contegix LLC. Contegix has since 
last summer been the managed hosting provider for the Spring Framework 
support forums, along with the Interface21 web site. Along with the 
absolutely excellent service they've provided during this time, the 
hosting for the forums has always been offered to us at a subsidized price.

The new website is now running on the same server as the forums, sharing 
the same bandwidth and hosting. I'm sure we'll continue to get excellent 
service from Contegix, and can highly recommend them to anybody looking 
for managed hosting.

Regards,
Colin

Colin Sampaleanu wrote:

> I'm happy to announce that a new, enhanced 
> http://www.springframework.org is now live!
>
> The site, sporting a new look and driven by a dynamic content 
> management engine, should serve the needs of the Spring community much 
> better. Expect the look and feel, as well as the capabilities of the 
> site, to continue to evolve.
>
> Thanks to Interface21 for sponsoring the installation, design and 
> hosting of the new site.
>
> (Note that because of DNS caching, it may be up to an hour from the 
> time of this email before you can actually see the new site).
>


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

[Springframework-developer] Re: Building WebFlow samples

[<kat...@ho...>]

It's step 3, "tweak the copied 'build.properties'" that isn't straight 
forward (it's important to get people up and running ASAP). The entry:

# location where development tools reside (e.g apps, libs, templates, etc.)
devtools.dir=c:/development/devtools

...leaves you scratching your head and reading through the build files 
to see where they should point to. While we should leave the property 
names as is (unless you do a complete refactor), how about some better 
default values and descriptions. E.g.

# location of spring root directory
devtools.dir=c:/java/spring-framework-1.2-rc2

# location where spring lib dependencies reside
devtools.lib.dir=${devtools.dir}/lib

# location of spring.jar
spring.dir=${devtools.dir}/dist

... or am I on the wrong track? I'd presume everyone would organise 
their java library directories differently, so a reference to a spring 
root directory is the essential property (again maybe a refactor of 
property names is required). What do you think?

Finally, you could just combine all the Ant commands required to:
1. build alljars webflow.jar webflow.support.jar

...which is still quite readable, and less steps.

PS. My problem below was missing the webflow.support.jar. Thanks for the 
   help.

Keith Donald wrote:
> I updated the readme.txt instructions.  Please let me know if these could
> still be improved.
> 
> /*
>  * webflow-samples
>  *
>  * phonebook - central sample demonstrating most webflow features
>  * itemlist - demonstrates application transaction tokens and expired flow
> cleanup
>  * fileupload - demonstrates multipart file upload with webflow
>  * birthdate - demonstrates Struts integration and the MultiAction
>  * sellitem - demonstrates a wizard with conditional transitions and
> continuations
>  *
>  * @author Keith Donald
>  * @since Mar 2005
>  * @version $Id: readme.txt,v 1.2 2005/04/11 06:19:53 kdonald Exp $
>  */
> 
> HOW TO BUILD WEBFLOW SAMPLES - FROM RELEASED DISTRIBUTION
> 
> 1. copy in the template 'build.properties' file in the same directory as
> this file to the root directory of the sample you wish to run.
> 
> 2. cd to the root directory of the sample you wish to run.
> 
> 3. tweak the copied 'build.properties' to your environment
> 
> 4. tweak 'build.bat' to point your environemnt so the ant build system can
> execute.
> 
> 5. run 'build dist' to build the application .war file, ready for
> deployment.
> 
> 6. if tomcat is installed on your system, run 'build tomcat.server.start' to
> start it and deploy the
> sample application in one step.
> 
> 7. access the sample at the appropriate URL, e.g
> http://localhost:8080/phonebook
> 
> HOW TO BUILD WEBFLOW SAMPLES - FROM CVS
> 
> From the spring root directory, execute from the command line:
> 
> 1. build alljars
> 
> 2. build webflow.jar
> 
> 3. build webflow.support.jar
> 
> 4. Proceed with the RELEASED DISTRIBUTION instructions above, customizing
> your local build.properties for each sample as necessary.  Note: If all want
> to do is build the sample .war file for manual deployment, you shouldn't
> have to do any build.properties customization--the default properties will
> suffice.  Property customization is only necessary if you have custom paths
> to dependent jar files or wish to automate deployment with a local tomcat
> installation.
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf Of
> kat...@ho...
> Sent: Thursday, May 05, 2005 1:04 AM
> To: spr...@li...
> Subject: [Springframework-developer] Building WebFlow samples
> 
> I was building the phonebook sample and found it wouldn't compile as the 
> sandbox classes were missing. How is everyone else obtaining/generating 
> the samples?
> 
> I added a patch (see below) which fixes the problem - but there may be 
> another approach. What are other doing? :)
> 
> If there is a better way, maybe we can improve the build instructions in 
> the distro.
> 
> Cheers.
> 
> 
> Compiling 9 source files to 
> C:\work\spring\samples\webflow\phonebook\target\classes
> C:\work\spring\samples\webflow\phonebook\src\org\springframework\samples\pho
> nebook\web\flow\PersonDetailFlowBuilder.java:18: 
> package org.springframework.binding.convert does not exist
> import org.springframework.binding.convert.ConversionExecutor;
> 
> 
> ===================================================================
> RCS file: /cvsroot/springframework/spring/builds/build.xml,v
> retrieving revision 1.2
> diff -u -r1.2 build.xml
> --- build.xml	27 Apr 2005 00:14:44 -0000	1.2
> +++ build.xml	5 May 2005 04:44:26 -0000
> @@ -15,6 +15,7 @@
>   		<pathelement location="${target.classes.dir}" />
>   		<pathelement location="${commons.logging.jar}" />
>   		<pathelement location="${spring.jar}" />
> +		<pathelement location="${spring.sandbox.jar}" />
>   		<pathelement location="${spring.mock.jar}" />
>   	</path>
> 
> 
> 
> -------------------------------------------------------
> 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=20
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> -------------------------------------------------------
> 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=20

[Springframework-developer] spring Build Failed

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

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

Re: [Springframework-user] Re: [Springframework-developer] New www.springframework.org site is live!

[Matt R. <li...@ra...>]

You rock Colin!

Thanks,

Matt

On May 5, 2005, at 4:01 PM, Colin Sampaleanu wrote:

> Ok, for historical purposes, I've internally redirected (i.e. it will 
> be invisible to requesters)
>   http://www.springframework.org/docs/api/XXXXXXX
> to the current production version Javadocs. In the same fashion,
>   http://www.springframework.org/docs/reference/XXXXXXX
> is redirected to the current production version reference manual.
>
> On the new static site, I have created some symlinks. So you can do
>   http://static.springframework.org/spring/docs/1.1.5/api/XXXX
>   http://static.springframework.org/spring/docs/1.1.x/api/XXXX
>   http://static.springframework.org/spring/docs/current/api/XXXX
>
> and get to the same thing. On this basis, to access the 1.2 RC tree 
> you can do
>   http://static.springframework.org/spring/docs/1.2RC2/api/XXXX
>   http://static.springframework.org/spring/docs/1.2.x/api/XXXX
>
> The same thing for the reference manual.
>
> This means people can refer to a specific version of any release, the 
> current version of any point release (1.1.x, etc.), and the current 
> (most up to date) production version, period.
>
> Colin

Re: [Springframework-user] Re: [Springframework-developer] New www.springframework.org site is live!

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

Matt Raible wrote:

>
> On May 5, 2005, at 2:45 PM, Colin Sampaleanu wrote:
>
>> The CMS here is Drupal.
>>
>> It's certainly possible to handle historical URLs, and some already  
>> are. Most of the site is handled dynamically by Drupal, but
>>   /dtd
>> and
>>  /buttons
>> is redirected internally (invisibly) by Apache to the new
>>  http://static.springframework.org
>> site meant for completely static content like online documentation. 
>> It  was critical to do this to not break DTD URLs and existing 
>> button  links using the images directly from the Spring website.
>>
>> There is a question of what to do this for however. The old static  
>> structure was somewhat adhoc and simplistic. If you look at your  
>> example
>>    http://www.springframework.org/docs/api/org/springframework/web/ 
>> servlet/mvc/SimpleFormController.html
>> there's no product name (spring base library vs. webflow vs whatever  
>> other lib) in there, and there's no version number. Under the new  
>> structure, this is available as
>>   http://static.springframework.org/spring/docs/1.1.5/api/org/ 
>> springframework/web/servlet/mvc/SimpleFormController.html
>
>
> I can see your point.  However, in Spring Live - whenever I've  
> mentioned a class name, I've linked to it's javadoc - making it easy  
> for readers to look up and see more information about a class.  I did  
> this on a couple while writing and the tech editors and readers liked  
> it so much, I did it for all of them.  I'd hate to have to go back  
> through and change all these links to point to a specific product and  
> version number.
>
> Matt

Ok, for historical purposes, I've internally redirected (i.e. it will be 
invisible to requesters)
   http://www.springframework.org/docs/api/XXXXXXX
to the current production version Javadocs. In the same fashion,
   http://www.springframework.org/docs/reference/XXXXXXX
is redirected to the current production version reference manual.

On the new static site, I have created some symlinks. So you can do
   http://static.springframework.org/spring/docs/1.1.5/api/XXXX
   http://static.springframework.org/spring/docs/1.1.x/api/XXXX
   http://static.springframework.org/spring/docs/current/api/XXXX

and get to the same thing. On this basis, to access the 1.2 RC tree you 
can do
   http://static.springframework.org/spring/docs/1.2RC2/api/XXXX
   http://static.springframework.org/spring/docs/1.2.x/api/XXXX

The same thing for the reference manual.

This means people can refer to a specific version of any release, the 
current version of any point release (1.1.x, etc.), and the current 
(most up to date) production version, period.

Colin

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

RE: [Springframework-developer] Re: [Springframework-user] Delayed association of transaction with session

[James C. <jim...@do...>]

Good idea Erwin. I'll give that a try.

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of Erwin Vervaet
> Sent: Thursday, May 05, 2005 10:29 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Re: [Springframework-user]
> Delayed association of transaction with session
>=20
> One way to make it more elegant is to use an object initialisation
> callback
> interface. That way the controllers can pass this initialisation =
strategy
> into the service layer, which will call it to initialize any objects
> ("excercizing" the lazy associations) it returns back to the =
controller.
> As
> a result you have a situation where
>=20
> 1) the controllers "define" (by implementing the initialisation =
callback
> interface, mostly using an anonymous inner class) how to initialize =
the
> objects retreived from the service layer, which can be specific to =
that
> controller and its views
>=20
> 2) no explosion of methods on the service layer to support all =
possible
> usage scenarios by the controllers
>=20
> 3) for optimisation you still have the option of defining a =
specialized
> service method which is backed by a specialized query
>=20
> Erwin Vervaet
> erw...@er...
> ----- Original Message -----
> From: "James Cook" <jim...@do...>
> To: <spr...@li...>
> Sent: Thursday, May 05, 2005 3:11 PM
> Subject: RE: [Springframework-developer] Re: [Springframework-user]
> Delayed
> association of transaction with session
>=20
>=20
> That's the thread where I described a service layer approach that we =
began
> using when we ditched OSIV. We give our web-tier a service layer to
> interact
> with that defines a transactional boundary.
>=20
> It worked very well for us, except for the problem that Ugo Cei =
brought up
> regarding the ugliness of pre-loading lazy-loaded collections. Not =
really
> a
> problem, but not so elegant.
>=20
> jim
>=20
> > -----Original Message-----
> > > There are other workarounds that may be jammed in, but the ones I =
can
> > > think
> > > up are not exactly elegant. Perhaps this is simply a case of =
developer
> > > beware; a known side-effect to using the OSIV approach to web
> > development.
> > > I'd appreciate any advice on whether the framework can be coerced =
to
> > > eliminate one of the remaining flaws in this pattern.
> >
> > Also take a look at the following discussion, which details more of =
the
> > issues of OSIV:
> >
> >
> =
http://www.newsarch.com/archive/mailinglist/comp/java/springframework/use=
r
> > /msg03641.html
> >
> > Erwin
>=20
>=20
>=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
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=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