springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Spring IDE for Eclipse - Beans Configuration Support v1.0.1 (formerly known as SpringUI)

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

This is what I'm using:

Windows XP
Eclipse M8
Graphical Editing Framework 3.0.0
Spring 1.0.1

To check your plugin status:

Help - Software Updates - Manage Configuration ...

Click 'Show Disabled Features' if you don't see something that should be there.

You could try downloading the Integration Build: I20040330 from the GEF downloads.

Thomas



Anand Sharma wrote:

>So, here's what I have:
>
>Win XP
>Eclipse M8
>GEF runtime 2.1.3
>Spring 1.0.1
>
>While the Spring "View" works as always (along with the "new" contextual
>'Properties' option), the graph functionality does not work. Here's
>what happens:
>
>I open a project which is 'Spring enabled" and then open
>'applicationContext.xml' file in the Editor.
>
>Upon right-click, I see the option "Show in Spring Beans View".
>It does not do anything. No errors, nothing. Just makes the typical
>'beep' sound, the sound which the OS gives when you try doing something
>which is not allowed.
>
>Am I missing something here? Does the plugin work with M8? Also,
>is there a way to know that the GEF is installed correctly. The way
>I installed GEF runtime was a)Download the GEF runtime (not the SDK)
>b)Unzip it c)Copy contents from plugins folder into 'Eclipse-M8' plugins
>and copy contents from features folder into 'Eclipse-M8' features.
>d)Restart Eclipse.
>
>Any help will be really appreciated.
>
>Thx
>
>Anand
>
>On Sat, 24 Apr 2004, Torsten Juergeleit wrote:
>
>  
>
>>I am pleased to announce a new release (1.0.1) of the
>>Spring IDE for Eclipse.
>>
>>This is an update to the Eclipse plugin "SpringUI"
>>(http://springui.sf.net/) which recently migrated from
>>a separate project into a sub-project of the Spring
>>Framework main project
>>(http://http://www.springframework.org/spring-ide/eclipse/).
>>
>>It provides the following new features:
>>
>>* the beans view now supports a context menu (with
>>currently only one entry "properties" which opens the
>>Spring project configuration property page)
>>
>>* a new toolbar button in the beans view allows to
>>open Eclipse's properties sheet view
>>
>>* a new (read-only) editor which displays a graph from
>>all beans defined in a single config file or a config
>>set (sample screen ->
>>http://www.springframework.org/spring-ide/eclipse/BeansGraph.png
>>)
>>
>>
>>You can find further information here:
>>http://http://www.springframework.org/spring-ide/eclipse/
>>
>>The update site for the Eclipse update manager can be
>>found here:
>>http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/
>>
>>Cheers,
>>Torsten
>>
>>
>>	
>>		
>>__________________________________
>>Do you Yahoo!?
>>Yahoo! Photos: High-quality 4x6 digital prints for 25¢
>>http://photos.yahoo.com/ph/print_splash
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
>>For a limited time only, get FREE Ground shipping on all orders of $35
>>or more. Hurry up and shop folks, this offer expires April 30th!
>>http://www.thinkgeek.com/freeshipping/?cpg=12297
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>    
>>
>
>  
>

Re: [Springframework-developer] Spring IDE for Eclipse - Beans Configuration Support v1.0.1 (formerly known as SpringUI)

[Anand S. <ana...@mo...>]

So, here's what I have:

Win XP
Eclipse M8
GEF runtime 2.1.3
Spring 1.0.1

While the Spring "View" works as always (along with the "new" contextual
'Properties' option), the graph functionality does not work. Here's
what happens:

I open a project which is 'Spring enabled" and then open
'applicationContext.xml' file in the Editor.

Upon right-click, I see the option "Show in Spring Beans View".
It does not do anything. No errors, nothing. Just makes the typical
'beep' sound, the sound which the OS gives when you try doing something
which is not allowed.

Am I missing something here? Does the plugin work with M8? Also,
is there a way to know that the GEF is installed correctly. The way
I installed GEF runtime was a)Download the GEF runtime (not the SDK)
b)Unzip it c)Copy contents from plugins folder into 'Eclipse-M8' plugins
and copy contents from features folder into 'Eclipse-M8' features.
d)Restart Eclipse.

Any help will be really appreciated.

Thx

Anand

On Sat, 24 Apr 2004, Torsten Juergeleit wrote:

> I am pleased to announce a new release (1.0.1) of the
> Spring IDE for Eclipse.
>=20
> This is an update to the Eclipse plugin "SpringUI"
> (http://springui.sf.net/) which recently migrated from
> a separate project into a sub-project of the Spring
> Framework main project
> (http://http://www.springframework.org/spring-ide/eclipse/).
>=20
> It provides the following new features:
>=20
> * the beans view now supports a context menu (with
> currently only one entry "properties" which opens the
> Spring project configuration property page)
>=20
> * a new toolbar button in the beans view allows to
> open Eclipse's properties sheet view
>=20
> * a new (read-only) editor which displays a graph from
> all beans defined in a single config file or a config
> set (sample screen ->
> http://www.springframework.org/spring-ide/eclipse/BeansGraph.png
> )
>=20
>=20
> You can find further information here:
> http://http://www.springframework.org/spring-ide/eclipse/
>=20
> The update site for the Eclipse update manager can be
> found here:
> http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/
>=20
> Cheers,
> Torsten
>=20
>=20
> =09
> 	=09
> __________________________________
> Do you Yahoo!?
> Yahoo! Photos: High-quality 4x6 digital prints for 25=A2
> http://photos.yahoo.com/ph/print_splash
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=3D12297
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

--=20
----------------------------
Anand Sharma
http://www.morebytes.com

"When in doubt, follow your heart"

Re: [Springframework-developer] Standalone alias definitions in the BeanFactory/ApplicationContext

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

Tom,

That's a decent technique, and does cover most cases. I think however a 
standalone alias definition would cover the remaining cases, and would 
also be clearer some of the time w/respect to being a very explicit 
'wiring-up' of components.

There's actually another way to handle this too that I can think of, and 
that's to add in a FactoryBean that simply returns a target bean that's 
passed to it as a ref. It'd be very slightly less efficient than a real 
alias, but I don't think it would make much of a difference in practice.

Tom Turelinckx wrote:

>Colin,
>
>In our project, we have some common functionality that's developed
>separately and included as a jar file, so I've been thinking about this
>as well.
>
>As the common beans are usually defined in the app's own xml file,
>however, you can use the regular alias functionality:
>
><bean id="myDataSource"
>name="com.whatever.componenta.dataSource,com.something.componentb.dataSource"
>class="...">
>...
></bean>
>
>The standalone alias functionality would only be needed if you wanted to
>make a bean of component A available with a different name to component
>B. I don't think that's a common scenario...
>
>Best regards,
>Tom.
>
>On Fri, 23 Apr 2004 09:08:05 -0400, "Colin Sampaleanu"
><col...@ex...> said:
>  
>
>>I've been thinking about how you would go about assembling multiple 
>>spring-enabled components from different sources. Consider component A 
>>and component B: both ship with an internal application context 
>>definition file, which defines the beans they work with, and ideally 
>>doesn't have to be changed at all, just used as one of the definition 
>>files making up a complete appContext. But both need to use a dataSource 
>>to feed to other beans. They could define the datasource themselves, but 
>>then you would have to to modify the config (or use an externaal 
>>property file), and the same data would have to be configured in a 
>>number of places. They could also just use a common bean name like 
>>dataSource, but then you have the problem that that name may conflict 
>>with another unrelated bean.
>>
>>So I think if a component is realistically going to be used by a 3rd 
>>party, it needs to name its beans in its appcontext with something like 
>>package unique ids. Then all that is needed is a way to map a component 
>>specific bean id to another id.
>>
>>So I propose we add the concept of a standalone alias to the 
>>BeanFactory/AppContext. In the xml variants, it would be a top level 
>><alias> element or something similar, and all it would do would provide 
>>an alias for an existing bean name.
>>
>>So component a for example would refer to the datasource as:
>>   com.whatever.componenta.dataSource
>>and component b woudl use for example:
>>   com.something.componentb.dataSource
>>
>>Now the app using these components would use a multi-file appcontext 
>>definition where two of the files come from the respective components, 
>>and one file is for the app itself, and in that it would provide aliases 
>>so the datasource can be found.
>>
>><alias from="com.whatever.componenta.dataSource" to="myDataSource"/>
>><alias from="com.something.componentb.dataSource" to="myDataSource"/>
>>
>>I think this is relatively trivial to implement, and would be pretty 
>>useful in these kinds of situations.
>>
>>What do you guys think?
>>
>>Regards,
>>Colin
>>    
>>

Re: [Springframework-developer] Standalone alias definitions in the BeanFactory/ApplicationContext

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

Colin,

In our project, we have some common functionality that's developed
separately and included as a jar file, so I've been thinking about this
as well.

As the common beans are usually defined in the app's own xml file,
however, you can use the regular alias functionality:

<bean id="myDataSource"
name="com.whatever.componenta.dataSource,com.something.componentb.dataSource"
class="...">
...
</bean>

The standalone alias functionality would only be needed if you wanted to
make a bean of component A available with a different name to component
B. I don't think that's a common scenario...

Best regards,
Tom.

On Fri, 23 Apr 2004 09:08:05 -0400, "Colin Sampaleanu"
<col...@ex...> said:
> I've been thinking about how you would go about assembling multiple 
> spring-enabled components from different sources. Consider component A 
> and component B: both ship with an internal application context 
> definition file, which defines the beans they work with, and ideally 
> doesn't have to be changed at all, just used as one of the definition 
> files making up a complete appContext. But both need to use a dataSource 
> to feed to other beans. They could define the datasource themselves, but 
> then you would have to to modify the config (or use an externaal 
> property file), and the same data would have to be configured in a 
> number of places. They could also just use a common bean name like 
> dataSource, but then you have the problem that that name may conflict 
> with another unrelated bean.
> 
> So I think if a component is realistically going to be used by a 3rd 
> party, it needs to name its beans in its appcontext with something like 
> package unique ids. Then all that is needed is a way to map a component 
> specific bean id to another id.
> 
> So I propose we add the concept of a standalone alias to the 
> BeanFactory/AppContext. In the xml variants, it would be a top level 
> <alias> element or something similar, and all it would do would provide 
> an alias for an existing bean name.
> 
> So component a for example would refer to the datasource as:
>    com.whatever.componenta.dataSource
> and component b woudl use for example:
>    com.something.componentb.dataSource
> 
> Now the app using these components would use a multi-file appcontext 
> definition where two of the files come from the respective components, 
> and one file is for the app itself, and in that it would provide aliases 
> so the datasource can be found.
> 
> <alias from="com.whatever.componenta.dataSource" to="myDataSource"/>
> <alias from="com.something.componentb.dataSource" to="myDataSource"/>
> 
> I think this is relatively trivial to implement, and would be pretty 
> useful in these kinds of situations.
> 
> What do you guys think?
> 
> Regards,
> Colin
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] [patch] Commons Validator: JavaScriptValidatorTag works like Struts

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

Developers,

Attached is a patch for the JavaScriptValidatorTag so that Spring's
Commons Validator works like it does with Struts.  I've tested it with
JavaScript generated in the page, as well as using a JSP to generate a
standalone JavaScript file.  Code often speaks better than words:

<html:javascript formName="user"/> - Generates a bunch of JavaScript
methods in the current page (read from validator-rules.xml).

OR:

<html:javascript formName="user" staticJavascript="false"/>
<script type="text/javascript" src="<c:url
value="/scripts/validator.jsp"/>"></script>

Where /scripts/validator.jsp is:

<%@ page language="java" contentType="javascript/x-javascript" %>
<%@ taglib uri="http://jakarta.apache.org/struts/tags-html"
prefix="html" %>

<html:javascript dynamicJavascript="false" staticJavascript="true"/>

I also patched build.xml so the .tld for commons-validator is included
in spring.jar/META-INF.

HTH,

Matt

[Springframework-developer] Spring IDE for Eclipse - Beans Configuration Support v1.0.1 (formerly known as SpringUI)

[Torsten J. <tju...@ya...>]

I am pleased to announce a new release (1.0.1) of the
Spring IDE for Eclipse.

This is an update to the Eclipse plugin "SpringUI"
(http://springui.sf.net/) which recently migrated from
a separate project into a sub-project of the Spring
Framework main project
(http://http://www.springframework.org/spring-ide/eclipse/).

It provides the following new features:

* the beans view now supports a context menu (with
currently only one entry "properties" which opens the
Spring project configuration property page)

* a new toolbar button in the beans view allows to
open Eclipse's properties sheet view

* a new (read-only) editor which displays a graph from
all beans defined in a single config file or a config
set (sample screen ->
http://www.springframework.org/spring-ide/eclipse/BeansGraph.png
)


You can find further information here:
http://http://www.springframework.org/spring-ide/eclipse/

The update site for the Eclipse update manager can be
found here:
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/

Cheers,
Torsten


	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash

[Springframework-developer] cheers BeerApp on MS-XP/Tomcat-5

[Tom K <tk...@co...>]

I=92m trying to learn Spring. With the example Beer App HYPERLINK
"http://www.springframework.org/news.html#baseBeans"http://www.springfra
mework.org/news.html#baseBeans
I am having difficulty getting HSSQL to work with Tomcat-5/Win XP. Would
anyone care to share their web.xml and server.xml file?
=20
Thanks in advance,
=20
Tom K.
=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.557 / Virus Database: 349 - Release Date: 12/30/2003
=20

[Springframework-developer] declaration must be well formed?

[Tom K <tk...@co...>]

I=92m using MyEclipse, and am getting this error on Springs *.xml file:
=20
=93The markup declarations contained or pointed to by the document type
declaration must be well-formed=94
=20
The error =93highlights=94 the first line below.. Any idea why?
=20
<?xml version=3D"1.0" encoding=3D"UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">
=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.557 / Virus Database: 349 - Release Date: 12/30/2003
=20

[Springframework-developer] Problems with the Servlet and HandlerMapping design

[<jo....@us...>]

Hi,

quite recently we started the porting of our webDAV/resource centric
app server/framework implementation to Spring, and right at the start
we run in to a couple of bugging inconveniences:

1) the FrameworkServlet forwards POST and GET requests to subclasses
   through the serviceWrapper(). That's fine for most web apps, but
   webDAV has a lot more methods, so we override service() to allow
   for these. However, since serviceWrapper has been made private, we
   have to copy/paste serviceWrapper into our subclass' service()...

   Would it be a solution to make serviceWrapper() protected instead,
   even if it in theory would make it possible for people to do
   something they shouldn't?

2) Being resource/url centric, and with a lot of functionality linked
   to dynamic resources based on different kinds of properties on
   these resources, our handler mapping is quite complex. We have two
   levels of mapping:

   - First we have the 'usual' HandlerMapping setup in Spring to
   decide what kind of 'application' should handle the request.

   - Then we have the applications, which is another level of
     HandlerMapping resolving the actual handler to use.

   Now, the problem we ran into was that since Spring chooses handlers
   by looking for HandlerMapping beans and running them in sequence,
   the 'application level' handler mappings is run at the first level.
   The workaround for this is to have these handler mappings subclass
   a copy/pasted version of AbstactHandlerMapping, where the
   'implements HandlerMapping' is removed.

   I'd like to avoid this duplication of code, but I'm a bit unsure
   about how to do it. Especially since it's bad timing to propose
   changing the overall design now :) Would it be OK to move the
   implementation of AbstractHandlerMapping to a new super class,
   which didn't implement HandlerMapping, and keep only the 'implement
   HandlerMapping' in AbstractHandlerMapping?

   This way I could sub class the super class to get the desired
   functionality without being discovered by Spring, and subclasses
   of AbstractHandlerMapping would remain the undisturbed.

What do you think? I could probably live with duplicating some code,
but I don't like it. And if I have these requirements, chances are
others will have, too?

BTW, congratulations on your 1.0(.1!) release, great work.

Haveaniceday,
Jo

Re: [Springframework-developer] README states usage of Velocity 1.4

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

The actually required Velocity version is still 1.3. We're shipping the =
Velocity 1.4 jar in the -with-dependencies download, though, to provide =
the most current recommended Velocity release. As a side note, Velocity =
1.4 could have been 1.3.2 anyway - there weren't too many changes, after =
all.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Hans Donner
Gesendet: Fr 23.04.2004 17:40
An: spr...@li...
Betreff: [Springframework-developer] README states usage of Velocity 1.4



Hi there,
I've notices that the README of 1.0.1 states the following

2. RELEASE INFO

(...) Integration is provided with (...) Velocity 1.3 (...)

Shouldn't that be v1.4 ?

Hans



-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=3D12297
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] README states usage of Velocity 1.4

[Hans D. <co...@po...>]

Hi there,
I've notices that the README of 1.0.1 states the following

2. RELEASE INFO

(...) Integration is provided with (...) Velocity 1.3 (...)

Shouldn't that be v1.4 ?

Hans

Re: [Springframework-developer] spring.jar only?

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

The Spring 1.0.x series will stick to the JAR file layout used by 1.0 =
final. So yes, simply replace spring.jar with the newer version.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Tom K
Gesendet: Do 22.04.2004 21:31
An: spr...@li...
Betreff: [Springframework-developer] spring.jar only?


When updating from Spring 1.0 to the latest. Does that mean that only =
the old spring.jar needs to be replaced with the new one or are other =
jar files involved?
=20
Tom K.
=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.557 / Virus Database: 349 - Release Date: 12/30/2003

[Springframework-developer] Standalone alias definitions in the BeanFactory/ApplicationContext

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

I've been thinking about how you would go about assembling multiple 
spring-enabled components from different sources. Consider component A 
and component B: both ship with an internal application context 
definition file, which defines the beans they work with, and ideally 
doesn't have to be changed at all, just used as one of the definition 
files making up a complete appContext. But both need to use a dataSource 
to feed to other beans. They could define the datasource themselves, but 
then you would have to to modify the config (or use an externaal 
property file), and the same data would have to be configured in a 
number of places. They could also just use a common bean name like 
dataSource, but then you have the problem that that name may conflict 
with another unrelated bean.

So I think if a component is realistically going to be used by a 3rd 
party, it needs to name its beans in its appcontext with something like 
package unique ids. Then all that is needed is a way to map a component 
specific bean id to another id.

So I propose we add the concept of a standalone alias to the 
BeanFactory/AppContext. In the xml variants, it would be a top level 
<alias> element or something similar, and all it would do would provide 
an alias for an existing bean name.

So component a for example would refer to the datasource as:
   com.whatever.componenta.dataSource
and component b woudl use for example:
   com.something.componentb.dataSource

Now the app using these components would use a multi-file appcontext 
definition where two of the files come from the respective components, 
and one file is for the app itself, and in that it would provide aliases 
so the datasource can be found.

<alias from="com.whatever.componenta.dataSource" to="myDataSource"/>
<alias from="com.something.componentb.dataSource" to="myDataSource"/>

I think this is relatively trivial to implement, and would be pretty 
useful in these kinds of situations.

What do you guys think?

Regards,
Colin

RE: [Springframework-developer] Portlet support

[Jeff B. <jwb...@ta...>]

Yes, I'm interested in the same answers. What servers are you looking at?
I'm reviewing eXo, GridSphere & Liferay - all are 168 compliant.  All 3 use
Hibernate. eXo uses pico ioc. eXo & Liferay build on Struts. They lack the
same quality documentation/support that I'm used to over here at Spring. eXo
has a really good eclipse plugin and uses JSF. I don't know if JSF is good
or bad, or if that's the only view/render option. I assume they must have
taglib if 168 compliant. So why JSF? Liferay lacks the most in documentation
and requires session beans. I really just started reviewing GridSphere today
and it looks really good. It appears to be a webSphere portal server clone.
They have this concept of dynamic actions that are passed to the JSP/view.
Anyone know about this?

I'd welcome comments from others who have experience / knowledge with 168
compliant portal servers.

Jeff W Boring


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rainer Schmitz
Sent: Thursday, April 22, 2004 9:26 AM
To: spr...@li...
Subject: [Springframework-developer] Portlet support


I followed the portlet thread a few days ago. I'm just starting to learn
about portlet development and as a Spring user I would like to use a
Portlet / Spring integration from the beginning.

Are there any examples on how to compbine portlets and spring? What's
the state of the FrameworkPortlet development?

Rainer



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

[Springframework-developer] spring.jar only?

[Tom K <tk...@co...>]

When updating from Spring 1.0 to the latest. Does that mean that only
the old spring.jar needs to be replaced with the new one or are other
jar files involved?
 
Tom K.
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.557 / Virus Database: 349 - Release Date: 12/30/2003
 

[Springframework-developer] OT: was (SpringEnabledTestCase)

[Ronald H. <ro...@co...>]

Yes it looks nice, thats true, but now the use of it. I am probably 
exagerating this but....
Now I would like to know what is happening to this particular subject. 
So I go to the confluence
webspace, login, search for the subject that I would like then click 
watch this space, and I will receive
emails when something changes, so I can go back to the website, login 
again, search for the update and
see that someone removed a whitespace?

Or without confluence and the mail list is used it just arives in my 
mail box. Hmm tough question.

I can see the use for confluence in some aspects, like editing large 
documents and seeing the changes
someone made, but not for discussions and questions. Not every 
communication has to be done using the
newest techniques just because they are available and new

Cheers
Ronald

Choy Rim wrote:

>Confluence looks a pretty full-featured wiki/documentation/collaboration
>tool. Like a wiki, you can edit any page. Unlike your average wiki, You
>can watch a page or a space and be notified when someone changes it.
>
>And the code formatting and searchability are just great. Try it:
>
>http://opensource.atlassian.com/confluence/spring/homepage.action
>
>type "test case" in the Quick Search box.
>
>  
>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On
>>    
>>
>Behalf
>  
>
>>Of Ronald Haring
>>Sent: Wednesday, April 21, 2004 10:59 AM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] SpringEnabledTestCase
>>
>>Personally I am not a big fan of wiki and wiki-like app, so I would
>>    
>>
>not
>  
>
>>like to see the discussions moved there.
>>The other reason why I dont want it (exlusive) on wiki is that the
>>mailling list doesnt require me to go to a page and check on the
>>    
>>
>ongoing
>  
>
>>discussions, it just arrives in my mail and I can read it anytime.
>>    
>>

Re: [Springframework-developer] Spring Framework 1.0.1 released

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

Colin,

Excellent, I'm in the process of updating index.html and news.html with the new
announcement - should be up there shortly.

Thomas


Quoting Colin Sampaleanu <col...@ex...>:

> I've now also updated the HTML manual on the website, from my own build..=
> .
> 
> Colin Sampaleanu wrote:
> 
> > I have updated the PDF on the website, and the new JavaDocs are in the=20
> > process of uploading.
> >
> > W/regards to the HTML docs, I just realized that we don't seem to=20
> > included them in the distros. This is not a big deal in terms of=20
> > updating the website, I can generate them locally. But was their=20
> > omission in the distros intentional?
> >
> > Regards,
> > Colin
> >
> > j=FCrgen h=F6ller [werk3AT] wrote:
> >
> >> Dear Spring community,
> >>
> >> I'm pleased to announce that Spring Framework 1.0.1 has just been=20
> >> released. This is a bugfix and minor enhancement release; the most=20
> >> important fixes and new features are:
> >>
> >> * added Struts ActionSupport and DispatchActionSupport base classes,=20
> >> for easy access to a Spring context
> >> * added Struts ContextLoaderPlugIn and DelegatingActionProxy,=20
> >> superseding Don Brown's Spring Struts Plugin
> >> * reworked ComponentControllerSupport class for Tiles to be=20
> >> compatible with both Struts 1.1 and Struts 1.2
> >>
> >> * fixed Hibernate/JTA synchronization cleanup in case of Hibernate=20
> >> flushing failure on commit
> >> * added support for transaction-scoped Hibernate Sessions with plain=20
> >> JTA or EJB CMT, without JtaTransactionManager
> >> * fixed JdbcTemplate's "queryForList" to correctly handle a single=20
> >> row with a single column as result
> >>
> >> * XmlApplicationContexts support file patterns as config locations=20
> >> (e.g. "/WEB-INF/*-context.xml")
> >> * SQLErrorCodesFactory caches database product name to avoid=20
> >> unnecessary metadata lookups
> >> * factored out message code resolution into MessageCodesResolver=20
> >> strategy
> >>
> >> * refined internals of the AOP framework, for clearer subpackage=20
> >> interdependencies
> >> * refined support for array/List/Map properties in BeanWrapperImpl
> >> * refined AbstractMessageSource internals, for clearer handling of=20
> >> fallbacks
> >>
> >> As always, see the changelog for details.
> >>
> >> We particularly encourage users of Spring's Hibernate/JTA integration=20
> >> to update promptly, to avoid any issues in case of flushing failures.=20
> >> Furthermore, users of Don Brown's Spring Struts Plugin are encouraged=20
> >> to switch to the new integration classes.
> >>
> >> Regards,
> >>
> >> Juergen
> >> =20
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] Spring Framework 1.0.1 released

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

I've now also updated the HTML manual on the website, from my own build..=
.

Colin Sampaleanu wrote:

> I have updated the PDF on the website, and the new JavaDocs are in the=20
> process of uploading.
>
> W/regards to the HTML docs, I just realized that we don't seem to=20
> included them in the distros. This is not a big deal in terms of=20
> updating the website, I can generate them locally. But was their=20
> omission in the distros intentional?
>
> Regards,
> Colin
>
> j=FCrgen h=F6ller [werk3AT] wrote:
>
>> Dear Spring community,
>>
>> I'm pleased to announce that Spring Framework 1.0.1 has just been=20
>> released. This is a bugfix and minor enhancement release; the most=20
>> important fixes and new features are:
>>
>> * added Struts ActionSupport and DispatchActionSupport base classes,=20
>> for easy access to a Spring context
>> * added Struts ContextLoaderPlugIn and DelegatingActionProxy,=20
>> superseding Don Brown's Spring Struts Plugin
>> * reworked ComponentControllerSupport class for Tiles to be=20
>> compatible with both Struts 1.1 and Struts 1.2
>>
>> * fixed Hibernate/JTA synchronization cleanup in case of Hibernate=20
>> flushing failure on commit
>> * added support for transaction-scoped Hibernate Sessions with plain=20
>> JTA or EJB CMT, without JtaTransactionManager
>> * fixed JdbcTemplate's "queryForList" to correctly handle a single=20
>> row with a single column as result
>>
>> * XmlApplicationContexts support file patterns as config locations=20
>> (e.g. "/WEB-INF/*-context.xml")
>> * SQLErrorCodesFactory caches database product name to avoid=20
>> unnecessary metadata lookups
>> * factored out message code resolution into MessageCodesResolver=20
>> strategy
>>
>> * refined internals of the AOP framework, for clearer subpackage=20
>> interdependencies
>> * refined support for array/List/Map properties in BeanWrapperImpl
>> * refined AbstractMessageSource internals, for clearer handling of=20
>> fallbacks
>>
>> As always, see the changelog for details.
>>
>> We particularly encourage users of Spring's Hibernate/JTA integration=20
>> to update promptly, to avoid any issues in case of flushing failures.=20
>> Furthermore, users of Don Brown's Spring Struts Plugin are encouraged=20
>> to switch to the new integration classes.
>>
>> Regards,
>>
>> Juergen
>> =20
>

Re: [Springframework-developer] FieldError and nested properties

[Rob R. <rob...@ur...>]

Wow, how about that for timing. That's perfect, I'm getting the
1.0.1 release now.=20

Thanks,
Rob

---- On Thu, 22 Apr 2004,
=3D?iso-8859-1?Q?j=3DFCrgen_h=3DF6ller_=3D5Bwerk3AT=3D5D?=3D
(jue...@we...) wrote:

> In Spring 1.0.1 which has been just released a couple of hours
ago, you'll find a
> MessageCodesResolver interface with a
DefaultMessageCodesResolver implementation. DataBinder has a
> setMessageCodesResolver method that allows to specify a custom
resolver.
>=20
> FieldError no longer generates its own error codes; this is
delegated to the MessageCodesResolver.
> Your requirement to generate additional codes could be a
candidate for a custom MessageCodesResolver
> implementation.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
>
[mailto:spr...@li...]On
Behalf
> Of Rob Rudin
> Sent: Thursday, April 22, 2004 2:52 PM
> To: Choy Rim
> Subject: [Springframework-developer] FieldError and nested
properties
>=20
>=20
> Got a question about FieldError and validation. I know it's
> created by DataBinder, and the ctor for FieldError creates
three
> codes for message lookup, which is nice. However, we'd like
for
> additional codes to be generated in the case of nested
> properties.
>=20
> Our problem is that we have several different UI's where
> coordinate information is entered, but the coordinate
properties
> are at different nested paths, so we can't have something like
> "typeMismatch.latitude.degrees". Instead, we'd need to do
> "typeMismatch.someObject.someProperty.latitude.degrees" and so
> on for all of the different objects that have coordinate
> properties.=20
>=20
> We're going to write a NestedFieldError class that looks for
> nested properties in the "field" value when a FieldError is
> constructed. This will allow us to have a generic
> "typeMismatch.latitude.degrees", or even a
> "typeMismatch.degrees" error message, which will be very nice.
> Unfortunately, this will involve extending DataBinder as well
so
> that it uses our NestedFieldError class. We'll have to
override
> the bind method.
>=20
> I'm wondering - has anyone else needed this functionality?
Would
> it be too special-case to add it to the Spring validation
> package? What could at least be done is to factor out how
> DataBinder creates instances of FieldError - maybe toss it
into
> a protected method so that a subclass could easily override
it,
> or just refactor it into something pluggable and use the
current
> approach as the default.
>=20
> Rob
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and
CEO of
> GenToo technologies. Learn everything from fundamentals to
system
>
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and
CEO of
> GenToo technologies. Learn everything from fundamentals to
system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20

Re: [Springframework-developer] Spring Framework 1.0.1 released

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

I have updated the PDF on the website, and the new JavaDocs are in the=20
process of uploading.

W/regards to the HTML docs, I just realized that we don't seem to=20
included them in the distros. This is not a big deal in terms of=20
updating the website, I can generate them locally. But was their=20
omission in the distros intentional?

Regards,
Colin

j=FCrgen h=F6ller [werk3AT] wrote:

>Dear Spring community,
>=20
>I'm pleased to announce that Spring Framework 1.0.1 has just been releas=
ed. This is a bugfix and minor enhancement release; the most important fi=
xes and new features are:
>=20
>* added Struts ActionSupport and DispatchActionSupport base classes, for=
 easy access to a Spring context
>* added Struts ContextLoaderPlugIn and DelegatingActionProxy, supersedin=
g Don Brown's Spring Struts Plugin
>* reworked ComponentControllerSupport class for Tiles to be compatible w=
ith both Struts 1.1 and Struts 1.2
>=20
>* fixed Hibernate/JTA synchronization cleanup in case of Hibernate flush=
ing failure on commit
>* added support for transaction-scoped Hibernate Sessions with plain JTA=
 or EJB CMT, without JtaTransactionManager
>* fixed JdbcTemplate's "queryForList" to correctly handle a single row w=
ith a single column as result
>=20
>* XmlApplicationContexts support file patterns as config locations (e.g.=
 "/WEB-INF/*-context.xml")
>* SQLErrorCodesFactory caches database product name to avoid unnecessary=
 metadata lookups
>* factored out message code resolution into MessageCodesResolver strateg=
y
>=20
>* refined internals of the AOP framework, for clearer subpackage interde=
pendencies
>* refined support for array/List/Map properties in BeanWrapperImpl
>* refined AbstractMessageSource internals, for clearer handling of fallb=
acks
>=20
>As always, see the changelog for details.
>=20
>We particularly encourage users of Spring's Hibernate/JTA integration to=
 update promptly, to avoid any issues in case of flushing failures. Furth=
ermore, users of Don Brown's Spring Struts Plugin are encouraged to switc=
h to the new integration classes.
>=20
>Regards,
>=20
>Juergen
> =20
>

Re: [Springframework-developer] JdbcUtils.extractDatabaseMetaData

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

Juergen,

That's a good change - I don't really like names that are too long.  I just
based the name on RowCallbackHandler.  Since we have other XxxCallback
interfaces this new name is better.

Thomas

Quoting "jürgen höller [werk3AT]" <jue...@we...>:

> Thomas,
> =20
> In a last minute change before the 1.0.1 release, I've renamed =
> DatabaseMetaDataCallbackHandler to DatabaseMetaDataCallback, in analogy =
> to PreparedStatementCallback/HibernateCallback/JdoCallback etc. In =
> particular for names that are long enough already, I suggest to stick to =
> *Callback for consistency. I hope you don't mind the change; I didn't =
> want to delay the release any longer.
> =20
> Juergen
> =20
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag =
> von Thomas Risberg
> Gesendet: Mi 21.04.2004 03:19
> An: spr...@li...
> Betreff: Re: [Springframework-developer] =
> JdbcUtils.extractDatabaseMetaData
> 
> 
> 
> 
> >
> >The javadoc of JdbcUtils.extractDatabaseMetaData says that the method =
> will never throw an exception, but it still throws a =
> MetaDataAccessException on any kind of failure. Shouldn't it simply log =
> exceptions and return null?
> >=20
> >
> That must have been an old comment that I forgot to change.  I have
> modified it to reflect that this method does throw a checked exception
> since we can't rely on the exception translation to be initialized when
> this method is called.  This method is infrequently used and I'd rather
> force the use of a catch block instead of relying on calling code to
> check for a null returned.
> 
> >
> >Furthermore, why is the DatabaseMetaDataCallbackHandler interface in =
> the jdbc.core package? It is just used in the jdbc.support package, =
> which shouldn't depend on jdbc.core (just the other way round). =
> Consequently, I suggest to move it to jdbc.support.
> >
> >=20
> >
> Good point.  I have moved it.
> 
> Thomas
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
> ck
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

[Springframework-developer] Portlet support

[Rainer S. <Rai...@ab...>]

I followed the portlet thread a few days ago. I'm just starting to learn 
about portlet development and as a Spring user I would like to use a 
Portlet / Spring integration from the beginning.

Are there any examples on how to compbine portlets and spring? What's 
the state of the FrameworkPortlet development?

Rainer

Re: [Springframework-developer] FieldError and nested properties

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

In Spring 1.0.1 which has been just released a couple of hours ago, =
you'll find a MessageCodesResolver interface with a =
DefaultMessageCodesResolver implementation. DataBinder has a =
setMessageCodesResolver method that allows to specify a custom resolver.

FieldError no longer generates its own error codes; this is delegated to =
the MessageCodesResolver. Your requirement to generate additional codes =
could be a candidate for a custom MessageCodesResolver implementation.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rob Rudin
Sent: Thursday, April 22, 2004 2:52 PM
To: Choy Rim
Subject: [Springframework-developer] FieldError and nested properties


Got a question about FieldError and validation. I know it's
created by DataBinder, and the ctor for FieldError creates three
codes for message lookup, which is nice. However, we'd like for
additional codes to be generated in the case of nested
properties.

Our problem is that we have several different UI's where
coordinate information is entered, but the coordinate properties
are at different nested paths, so we can't have something like
"typeMismatch.latitude.degrees". Instead, we'd need to do
"typeMismatch.someObject.someProperty.latitude.degrees" and so
on for all of the different objects that have coordinate
properties.=20

We're going to write a NestedFieldError class that looks for
nested properties in the "field" value when a FieldError is
constructed. This will allow us to have a generic
"typeMismatch.latitude.degrees", or even a
"typeMismatch.degrees" error message, which will be very nice.
Unfortunately, this will involve extending DataBinder as well so
that it uses our NestedFieldError class. We'll have to override
the bind method.

I'm wondering - has anyone else needed this functionality? Would
it be too special-case to add it to the Spring validation
package? What could at least be done is to factor out how
DataBinder creates instances of FieldError - maybe toss it into
a protected method so that a subclass could easily override it,
or just refactor it into something pluggable and use the current
approach as the default.

Rob


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

[Springframework-developer] FieldError and nested properties

[Rob R. <rob...@ur...>]

Got a question about FieldError and validation. I know it's
created by DataBinder, and the ctor for FieldError creates three
codes for message lookup, which is nice. However, we'd like for
additional codes to be generated in the case of nested
properties.

Our problem is that we have several different UI's where
coordinate information is entered, but the coordinate properties
are at different nested paths, so we can't have something like
"typeMismatch.latitude.degrees". Instead, we'd need to do
"typeMismatch.someObject.someProperty.latitude.degrees" and so
on for all of the different objects that have coordinate
properties. 

We're going to write a NestedFieldError class that looks for
nested properties in the "field" value when a FieldError is
constructed. This will allow us to have a generic
"typeMismatch.latitude.degrees", or even a
"typeMismatch.degrees" error message, which will be very nice.
Unfortunately, this will involve extending DataBinder as well so
that it uses our NestedFieldError class. We'll have to override
the bind method.

I'm wondering - has anyone else needed this functionality? Would
it be too special-case to add it to the Spring validation
package? What could at least be done is to factor out how
DataBinder creates instances of FieldError - maybe toss it into
a protected method so that a subclass could easily override it,
or just refactor it into something pluggable and use the current
approach as the default.

Rob

Re: [Springframework-developer] JdbcUtils.extractDatabaseMetaData

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

Thomas,
=20
In a last minute change before the 1.0.1 release, I've renamed =
DatabaseMetaDataCallbackHandler to DatabaseMetaDataCallback, in analogy =
to PreparedStatementCallback/HibernateCallback/JdoCallback etc. In =
particular for names that are long enough already, I suggest to stick to =
*Callback for consistency. I hope you don't mind the change; I didn't =
want to delay the release any longer.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Thomas Risberg
Gesendet: Mi 21.04.2004 03:19
An: spr...@li...
Betreff: Re: [Springframework-developer] =
JdbcUtils.extractDatabaseMetaData




>
>The javadoc of JdbcUtils.extractDatabaseMetaData says that the method =
will never throw an exception, but it still throws a =
MetaDataAccessException on any kind of failure. Shouldn't it simply log =
exceptions and return null?
>=20
>
That must have been an old comment that I forgot to change.  I have
modified it to reflect that this method does throw a checked exception
since we can't rely on the exception translation to be initialized when
this method is called.  This method is infrequently used and I'd rather
force the use of a catch block instead of relying on calling code to
check for a null returned.

>
>Furthermore, why is the DatabaseMetaDataCallbackHandler interface in =
the jdbc.core package? It is just used in the jdbc.support package, =
which shouldn't depend on jdbc.core (just the other way round). =
Consequently, I suggest to move it to jdbc.support.
>
>=20
>
Good point.  I have moved it.

Thomas



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