You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(55) |
Mar
(100) |
Apr
(203) |
May
(330) |
Jun
(190) |
Jul
(302) |
Aug
(323) |
Sep
(197) |
Oct
(245) |
Nov
(490) |
Dec
(330) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(194) |
Feb
(400) |
Mar
(416) |
Apr
(415) |
May
(359) |
Jun
(381) |
Jul
(491) |
Aug
(311) |
Sep
(291) |
Oct
(273) |
Nov
(355) |
Dec
(266) |
| 2005 |
Jan
(306) |
Feb
(303) |
Mar
(520) |
Apr
(346) |
May
(255) |
Jun
(221) |
Jul
(171) |
Aug
(247) |
Sep
(147) |
Oct
(125) |
Nov
(165) |
Dec
(65) |
| 2006 |
Jan
(90) |
Feb
(53) |
Mar
(121) |
Apr
(103) |
May
(113) |
Jun
(103) |
Jul
(104) |
Aug
(67) |
Sep
(78) |
Oct
(82) |
Nov
(78) |
Dec
(70) |
| 2007 |
Jan
(77) |
Feb
(76) |
Mar
(63) |
Apr
(30) |
May
(47) |
Jun
(41) |
Jul
(44) |
Aug
(44) |
Sep
(49) |
Oct
(33) |
Nov
(25) |
Dec
(21) |
| 2008 |
Jan
(45) |
Feb
(13) |
Mar
(15) |
Apr
(12) |
May
(9) |
Jun
(33) |
Jul
(30) |
Aug
(7) |
Sep
(20) |
Oct
(17) |
Nov
(20) |
Dec
(10) |
| 2009 |
Jan
(8) |
Feb
(5) |
Mar
(12) |
Apr
(17) |
May
(19) |
Jun
(97) |
Jul
(77) |
Aug
(33) |
Sep
(24) |
Oct
(41) |
Nov
(16) |
Dec
(32) |
| 2010 |
Jan
(24) |
Feb
(14) |
Mar
(50) |
Apr
(71) |
May
(70) |
Jun
(64) |
Jul
(45) |
Aug
(62) |
Sep
(32) |
Oct
(4) |
Nov
(12) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
(6) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(4) |
Feb
(8) |
Mar
(6) |
Apr
(10) |
May
(2) |
Jun
(3) |
Jul
(11) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(4) |
Feb
(1) |
Mar
(9) |
Apr
(1) |
May
(8) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(10) |
Dec
(8) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(12) |
May
(2) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(9) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(7) |
Oct
(9) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(7) |
Feb
(5) |
Mar
(5) |
Apr
(5) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(4) |
Sep
(6) |
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2017 |
Jan
(7) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Keith D. <ke...@in...> - 2006-06-10 18:36:49
|
Dear Spring Community,
We are pleased to announce that Spring Web Flow (SWF) 1.0 RC2 (Release
Candidate 2) has been released.
This release contains bug fixes and minor improvements.
NEW AND NOTEWORTHY
The new and noteworthy of 1.0 RC2 include:
* Support for passing newly launched flow executions input from the
calling environment (ExternalContext) in a configurable manner. By
default all request parameters are exposed as input. The flow may then
choose to map this input into its own local scope using its "input
mapper". This mapper defines the input contract for the flow which is
consistent regardless of whether the flow is started as a top-level flow
or as a subflow.
Consider the following request URL as an example:
http://localhost:8080/flights/search-flow?flightNumber=12345
By default, when this URL is accessed the backing FlowExecutor will place
the "flightNumber" request parameter into an "input map". The input map
is then passed to a new execution of the "search-flow".
Within the search-flow definition:
<flow start-state="executeSearch">
<input-mapper>
<mapping source="flightNumber" target="flowScope.flightNumber"/>
</input-mapper>
...
</flow>
The <input-mapper> above defines the flow's input contract, stating this
flow supports a "flightNumber" input attribute. When a flightNumber is
provided at startup it will be mapped into "flowScope" under the name
"flightNumber". The mapper is also capable of performing a type
conversion during the mapping operation.
To customize flow execution input map population, for example, to pull
attributes from the request path or some other external source, configure
the "FlowExecutorImpl.inputMapper" property.
* Support for flow execution and external redirects within a JSR168
Portlet environment. Combined with a continuation-based repository this
allows use of browser navigational buttons (back, refresh) within a
Portlet environment. Also in a Portlet environment we now expose a
"globalSessionMap" property for accessing attributes in Portlet Session
APPLICATION_SCOPE.
* A new repository factory named
"SingleKeyFlowExecutionRepositoryFactory". This implementation generates a
single unique identifier for each persistent flow execution. It is useful
for achieving 1.0 EA "conversation redirect" semantics--the case where
after every POST a REDIRECT-GET hits a stable "flow execution URL" which
embeds the constant flow execution key. See the NumberGuess sample for an
illustration.
* Introduction of a standalone "conversation" subsystem, which the
provided flow execution repository implementations delegate to for
demarcating logical conversations that manage flow execution state. This
conversation subsystem is fully decoupled from the rest of Spring Web
Flow, usable outside of SWF, and may evolve into its own independent
module over time. The central service interface consists of:
public interface ConversationService {
public Conversation beginConversation(ConversationParameters parameters);
public Conversation getConversation(ConversationId id);
public ConversationId parseConversationId(String encodedId); }
public interface Conversation {
public ConversationId getId();
public void lock();
public void end();
public Object getAttribute(String name);
public void setAttribute(String name, Object value);
public void removeAttribute(String name);
public void unlock();
}
When a new flow execution is launched and needs to be persisted beyond one
request the repository calls "beginConversation" to start a new logical
conversation and places attributes in conversation scope to track
execution state. Likewise, when a flow execution ends the governing
conversation also ends and any allocated state is cleaned up.
In the future we expect to offer robust features within this system,
including conversation monitoring and management via JMX as well as
conversation history and statistics. We also expect to prove its
applicability to other environments outside of Spring Web Flow. Special
thanks to Juergen Hoeller and Ben Hale for their help in the design of
this portable conversation service abstraction.
POTENTIAL USER AFFECTING CHANGES
With 1.0 RC2 there are a few potential user-affecting changes on the road
to 1.0 final. The following section notes them:
* In spring-webflow-dtd, we renamed 'resultName' and 'resultScope'
<action/> element attributes to 'result-name' and 'result-scope',
respectively, for consistency with other attribute and element names.
* The FormAction properties "bindOnSetupForm" and "validateOnBinding" were
removed for simplicity. Experience has shown these properties are rarely
used and have been a source of confusion for new users. As a better
alternative, to execute a data binding operation before entering a view
state simply invoke the "bind" action method from your flow definition.
To calculate if validation should occur for a bindAndValidate attempt,
override the single "validationEnabled(RequestContext)" hook.
* The FormAction "exposeFormObject" action method was removed. Simply use
"setupForm" which is preferred.
* The FlowExecutionRepository and FlowExecutor SPI interfaces both had
changes. Both interfaces were simplified. More logic is now encapsulated
behind a FlowExecutionRepository including the structure and format of
generated FlowExecutionKeys. In addition, the FlowExecutionRepository is
now strictly responsible for managing persistent flow executions and
nothing else. The additional concept of a "conversation" is no longer
known to the SWF core. This means several things:
- The overall repository interface is simpler, making it easier to
create custom FlowExecutionRepositories with custom FlowExecutionKeys.
- The SWF core lexicon is stronger: flow executors invoke flow
executions to execute flows. Executions that remain active beyond one
request are persisted to a repository.
- The default repository implementations choose to delegate to a
distinct "conversation subsystem" for tracking conversational state
driven by the execution system, but the dependency on this system is
fully encapsulated and is optional.
The FlowExecutor interface, the entry point into SWF, was also simplified
for callers. It now encapsulates knowledge of complex internal types such
as EventIds and FlowExecutionKeys and thus is overall easier to use.
* Along the same lines, support for the explicit "conversationRedirect"
was removed. This represents removal of the "conversationRedirect:"
'view' prefix and the "CONVERSATION" RedirectType. To achieve the same
logical redirect semantics with 1.0 RC2 simply configure a FlowExecutor
with redirectOnPause type FLOW_EXECUTION and a repositoryFactory of
SingleKeyFlowExecutionRepositoryFactory.
--
Spring Web Flow 1.0 RC2 further refines the reference manual, providing 50
pages on SWF usage. The manual is available on-line in HTML and PDF
forms.
One of the best ways to get started with Spring Web Flow is to review and
walkthrough the sample applications. We recommend reviewing all samples,
supplementing with reference manual material as needed from the start.
Ten sample applications ship with the 1.0 RC2 release, each demonstrating
a distinct set of product features. These samples are:
1. Phonebook - the original sample demonstrating most features (including
subflows)
2. Sellitem - demonstrates a wizard with conditional transitions, flow
execution redirects, conversational scope, and continuations
3. Flowlauncher - demonstrates all the possible ways to launch and resume
flows
4. Itemlist - demonstrates REST-style URLs and inline flows
5. Shippingrate - demonstrates Spring Web Flow together with Ajax
technology (thanks to Steven Devijver)
6. NumberGuess - demonstrates stateful beans and "single key" flow
execution redirects.
7. Birthdate - demonstrates Struts integration
8. Fileupload - demonstrates multipart file upload
9. Phonebook-Portlet - the phonebook sample in a Portlet environment
(notice how the flow definitions do not change)
10. Sellitem-JSF - the sellitem sample in a JSF environment
To build the sample applications for deployment in one step simply extract
the release archive, access the
projects/spring-webflow/build-spring-webflow directory and execute the
"ant dist" target. See the release readme.txt and
projects/spring-webflow/spring-webflow-samples/readme.txt for more
information on the release archive contents and samples, respectively.
All sample projects are Spring IDE projects directly importable into
Eclipse.
Thanks to everyone out there who supported this release. At this time we
expect the next release of SWF to be 1.0 final targeting the late June
timeframe. There is still the possibility we will have another 1.0
release candidate if warranted. Be sure to monitor the SWF homepage and
forums for updates.
Enjoy!
The Spring Web Flow Team
Keith Donald
Principal, Interface21
Lead, Spring Web Flow product development
M: 321-223-6735
W: 321-396-5182
F: 321-281-4221
http://www.interface21.com
|
|
From: <bu...@in...> - 2006-06-09 23:35:20
|
Snapshot has been uploaded to http://www.springframework.org/snaphots The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html). |
|
From: <bu...@in...> - 2006-06-08 22:34:26
|
Snapshot has been uploaded to http://www.springframework.org/snaphots The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html). |
|
From: <bu...@in...> - 2006-06-08 11:09:55
|
Snapshot has been uploaded to http://www.springframework.org/snaphots The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html). |
|
From: <bu...@in...> - 2006-06-07 20:48:53
|
Snapshot has been uploaded to http://www.springframework.org/snaphots The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html). |
|
From: <bu...@in...> - 2006-06-07 07:52:33
|
Snapshot has been uploaded to http://www.springframework.org/snaphots The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html). |
|
From: <bu...@in...> - 2006-06-06 19:01:08
|
Snapshot has been uploaded to http://www.springframework.org/snaphots The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html). |
|
From: <Nic...@we...> - 2006-06-06 14:52:04
|
I have a suggestion / enhancement for the Spring JDBC implementation of
using the JdbcDaoSupport class. It is an abstract class of it that
will do basic CRUD on a database.
I would like to get some input from the community to see if it may be
worth adding to spring to ease the maintenance for developers using the
JdbcDaoSupport / MappingSqlQuery classes. With the current
implementation of JdbcDaoSupport, I found creating *a lot* of duplicate
code just to access the DB in general. Note: This is by no means to
replace a ORM solution, but an extension to the Spring / JDBC option.
Here is a snippet of the code and what it does? If necessary or
everyone thinks this may be a good cause, then I can submit it to JIRA
for later addition.....but I want to get some feedback.
Here is a snippet of the code that I have used....If necessary, I can
e-mail a concrete implementation of this as well.
/////////////////////////////////////////
package com.wellsfargo.framework.dao.jdbc;
import java.sql.Types;
import java.util.List;
import org.springframework.jdbc.core.SqlParameter;
import org.springframework.jdbc.core.support.JdbcDaoSupport;
import org.springframework.jdbc.object.MappingSqlQuery;
import org.springframework.orm.ObjectRetrievalFailureException;
import com.wellsfargo.framework.util.SqlSyntaxUtil;
/**
* Class goals: -Ease the maintenance for mapping a POJO to a jdbc
resultset for
* INSERTS, UPDATES, DELETES, AND SELECTS.=20
*=20
* -Quick / Generic DB to POJO mapper using JDBC.
* -The class will do the following:=20
* -generic CRUD operation on a table. INSERT, UPDATE, SELECT,
DELETE.=20
* -SELECT All from a table.=20
* -SELECT All and passing in a WHERE clause.=20
* -SELECT one object in database table based on the primary key.=20
* -Uses PreparedStatements to allow the DB to compile/optimise the
querys.
*=20
* -This class will not do the following:=20
* -Try not to re-invent any ORM solutions such as hibernate,
iBatis, JDO.=20
* -No extreme object inherited table structures. Use an ORM
solution.
*=20
* -Why use this:=20
* -When it doesn't make sense to use an ORM, but you need to use
* JDBC but to make the coding aspect a bit easier with the=20
* spring / jdbc implementation.
*=20
* @author Nick Neuberger
*/
public abstract class BasicJdbcDaoSupport extends JdbcDaoSupport {
public BasicJdbcDaoSupport() {
super();
}
public abstract String getTableName();
public abstract String getPrimaryKey();
public abstract String getFieldNamesWithoutPrimaryKey();
/**
* This is used for the mapping of the resultset in the
BasicQuery class. It
* will create a new instance ie. new BlahObject() each time the
resultset
* is called.
*=20
* @return
*/
public abstract Class getPojoBean();
/**
* This gets the concrete implementation of the MappingSqlQuery
class. This
* will be used to map the resultset to each domain object on
any retrieval
* desired. This class then perform basic retrievals for all
SELECT
* operations for the concrete classes.
*=20
* @return
*/
public abstract MappingSqlQuery getMappingSqlQuery();
/**
* Gets all of the field names including the primary key for use
in SQL
* statements.
*=20
* @return
*/
public String getAllFieldNamesWithPrimaryKey() {
return getPrimaryKey() + ", " +
getFieldNamesWithoutPrimaryKey();
}
/**
* Gets the SQL Statement for a SELECT all with no where class
appeneded.
*=20
* @return
*/
public String getSQLSelectAll() {
return "SELECT " + getAllFieldNamesWithPrimaryKey() + "
FROM "
+ getTableName();
}
/**
* Returns the SQL statement used by a SQL SELECT / WHERE
PRIMARYKEY =3D ?
*=20
* @return
*/
public String getSQLSelectByPrimaryKey() {
return getSQLSelectAll() + " WHERE " + getPrimaryKey() +
" =3D ?";
}
/**
* Returns the SQL INSERT statement that will include the
primary key with it. This will add the number of question
* marks for the prepared statement based on the field count.
* @return
*/
public String getSQLInsertByPrimaryKey() {
String sql =3D "INSERT INTO "
+ getTableName()
+ " ("
+ getAllFieldNamesWithPrimaryKey()
+ ") VALUES ("
+ SqlSyntaxUtil
=09
.convertFieldsIntoQuestionCount(getAllFieldNamesWithPrimaryKey())
+ ")";
return sql;
}
/**
* Returns the SQL UPDATE statement that will include "all
field" in the update with a where clause
* based on the primary key of the table.
* @return
*/
public String getSQLUpdateByPrimaryKey() {
String sql =3D "UPDATE "
+ getTableName()
+ " SET "
+ SqlSyntaxUtil
=09
.convertFieldNamesToUpdateFieldNames(getFieldNamesWithoutPrimaryKey())
+ " WHERE " + getPrimaryKey() + " =3D ?";
return sql;
}
=09
/**
* Removes an object from the database passed in
*=20
* @param primarykey
* field.
*/
public void removeObjectByPrimaryKey(Object lId) {
getJdbcTemplate().update(
"DELETE FROM " + getTableName() + "
WHERE " + getPrimaryKey()
+ " =3D ?", new Object[] {
lId });
}
/**
* Performs a SELECT (ALL) FROM TABLE with no where clause.
*=20
* NOTE: Be careful on this operation. Basically this should be
used
* sparingly if your table is too big. This is not meant to
handle
* "thousands of records.
*=20
* @return
*/
public List getAll() {
List list =3D null;
MappingSqlQuery theMappingSqlQuery =3D
getMappingSqlQuery();
// set the required stuff to run a Select All operation.
theMappingSqlQuery.setDataSource(getDataSource());
theMappingSqlQuery.setSql(getSQLSelectAll());
theMappingSqlQuery.compile();
list =3D theMappingSqlQuery.execute();
return list;
}
/**
* Returns an object based on the primary key of the table.
*=20
* @param lId
* @return returns the pojo if found, if not, it will throw a
* ObjectRetrievalFailureException
* @see org.springframework.orm.ObjectRetrievalFailureException
*/
public Object getObjectByPrimaryKey(Object lId) {
Object object =3D getObjectByPrimaryKeyNoException(lId);
if (object =3D=3D null) {
throw new
ObjectRetrievalFailureException(getPojoBean(), lId);
}
return object;
}
/**
* Retrieve an Object by primary key. Doesn't throw an exception
if an empty
* list is found. Could be private or public....doesn't matter.
*=20
* @return Returns an empty object if it's not found.
*/
public Object getObjectByPrimaryKeyNoException(Object objectId)
{
Object object =3D null;
MappingSqlQuery theMappingSqlQuery =3D
getMappingSqlQuery();
// set the required stuff to run a Select All operation.
theMappingSqlQuery.setDataSource(getDataSource());
theMappingSqlQuery.setSql(getSQLSelectByPrimaryKey());
// add the params before the compile.
if(objectId instanceof Long) {
theMappingSqlQuery.declareParameter(new
SqlParameter(getPrimaryKey(), Types.INTEGER));
}
else {
theMappingSqlQuery.declareParameter(new
SqlParameter(getPrimaryKey(), Types.VARCHAR));
}
theMappingSqlQuery.compile();
// pass in the primary key id.
List list =3D theMappingSqlQuery.execute(new Object[] {
objectId });
if (!list.isEmpty()) {
object =3D list.get(0);
}
return object;
}
/**
* Determines if the object is persisted or not.
*=20
* Used internally / externally to determine if an update or an
insert
* statement is called on an incoming save of an object.
*=20
* @param lId
* @return
*/
public boolean isObjectPersisted(Object objectId) {
boolean bReturn =3D false;
Object object =3D
getObjectByPrimaryKeyNoException(objectId);
if (object !=3D null) {
bReturn =3D true;
logger.debug("Row / Object Found with Primary
Key of [" + objectId + "]");
}
else {
logger.debug("Row / Object NOT Found with
Primary Key of [" + objectId + "]");
}
return bReturn;
}
}
////////////////////////////////////////
Thanks,
Nick Neuberger
|
|
From: <bu...@in...> - 2006-06-06 06:08:42
|
Snapshot has been uploaded to http://www.springframework.org/snaphots The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html). |
|
From: <bu...@in...> - 2006-06-06 03:07:37
|
Snapshot has been uploaded to http://www.springframework.org/snaphots The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html). |
|
From: <bu...@in...> - 2006-06-06 03:05:01
|
Snapshot has been uploaded to http://www.springframework.org/snaphots The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html). |
|
From: Colin S. <col...@ex...> - 2006-06-06 03:01:47
|
The migration of spring-projects from cvs to svn is partially done. I killed a lot of time until I figured out that SourceForge's ability to import CVS or SVN repos or dumpfiles, respectively, seems to be completely broken if the files are compressed, although that's supposed to work. What I eneded up doing was rsyncing the CVS repo over, stripping everything except spring-projects, converting to an SVN dump file, and then uploading that dump file in non-compressed format. spring-projects may now be checked out via SVN from: https://svn.sourceforge.net//svnroot/springframework/spring-projects Note that this is a transitional layout, where it still combines common-build, spring-webflow, and spring-ws, albeit in a slightly cleaner format. The new layout may be viewed via http from: http://svn.sourceforge.net/viewcvs.cgi/springframework/spring-projects/ It does now download jars from online, using the http View of another SVN directory: http://svn.sourceforge.net/viewcvs.cgi/springframework/repos/ At this point, spring-webflow and spring-binding build. spring-webflow-samples, and all of spring-ws, should still fail. More later, I have to take off in a few hours. Colin |
|
From: Colin S. <col...@ex...> - 2006-06-06 02:36:13
|
spring-webflow and samples should now be building completely, from svn. Note that the source directories have been move to match maven conventions, since everybody needed to check out the source again anyway. On 6/4/2006 2:15 PM, Colin Sampaleanu wrote: > The migration of spring-projects from cvs to svn is partially done. > > I killed a lot of time until I figured out that SourceForge's ability > to import CVS or SVN repos or dumpfiles, respectively, seems to be > completely broken if the files are compressed, although that's > supposed to work. What I eneded up doing was rsyncing the CVS repo > over, stripping everything except spring-projects, converting to an > SVN dump file, and then uploading that dump file in non-compressed > format. > > spring-projects may now be checked out via SVN from: > https://svn.sourceforge.net//svnroot/springframework/spring-projects > > Note that this is a transitional layout, where it still combines > common-build, spring-webflow, and spring-ws, albeit in a slightly > cleaner format. The new layout may be viewed via http from: > http://svn.sourceforge.net/viewcvs.cgi/springframework/spring-projects/ > > It does now download jars from online, using the http View of another > SVN directory: > http://svn.sourceforge.net/viewcvs.cgi/springframework/repos/ > > At this point, spring-webflow and spring-binding build. > spring-webflow-samples, and all of spring-ws, should still fail. > > More later, I have to take off in a few hours. > > Colin > |
|
From: <bu...@in...> - 2006-06-06 02:24:45
|
Snapshot has been uploaded to http://www.springframework.org/snaphots The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html). |
|
From: Colin S. <col...@ex...> - 2006-06-06 01:57:39
|
spring-webflow is now completely finished, including the release build. Unfortunately spring-ws still needs to be done. It has been reorged to live under a top-level dir, and I have rdone the source (main and test) java dirs in maven format, I or somebody still needs to try building the 3 projects, and make sure dependencies are either avilable online at ibiblio, or checked into the new online repos, backed by svn. Arjen, I should be able to do this tomorrow night. If you have time, feel free to have a go. Just make sure to not check in anything that is already available at ibiblio. Colin On 6/4/2006 7:29 PM, Colin Sampaleanu wrote: > spring-webflow and samples should now be building completely, from > svn. Note that the source directories have been move to match maven > conventions, since everybody needed to check out the source again anyway. > > > On 6/4/2006 2:15 PM, Colin Sampaleanu wrote: > >> The migration of spring-projects from cvs to svn is partially done. >> >> I killed a lot of time until I figured out that SourceForge's ability >> to import CVS or SVN repos or dumpfiles, respectively, seems to be >> completely broken if the files are compressed, although that's >> supposed to work. What I eneded up doing was rsyncing the CVS repo >> over, stripping everything except spring-projects, converting to an >> SVN dump file, and then uploading that dump file in non-compressed >> format. >> >> spring-projects may now be checked out via SVN from: >> https://svn.sourceforge.net//svnroot/springframework/spring-projects >> >> Note that this is a transitional layout, where it still combines >> common-build, spring-webflow, and spring-ws, albeit in a slightly >> cleaner format. The new layout may be viewed via http from: >> http://svn.sourceforge.net/viewcvs.cgi/springframework/spring-projects/ >> >> It does now download jars from online, using the http View of another >> SVN directory: >> http://svn.sourceforge.net/viewcvs.cgi/springframework/repos/ >> >> At this point, spring-webflow and spring-binding build. >> spring-webflow-samples, and all of spring-ws, should still fail. >> >> More later, I have to take off in a few hours. >> >> Colin >> > > |
|
From: <bu...@in...> - 2006-06-03 14:42:07
|
Snapshot has been uploaded to http://www.springframework.org/snaphots The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html). |
|
From: <bu...@in...> - 2006-06-03 04:45:00
|
Snapshot has been uploaded to http://static.springframework.org/downloads/nightly/spring-webflow
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring-webflow/build/index.html).
|
|
From: <bu...@in...> - 2006-06-03 01:52:44
|
Snapshot has been uploaded to http://www.springframework.org/snaphots The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html). |
|
From: <bu...@in...> - 2006-06-02 13:04:31
|
Snapshot has been uploaded to http://www.springframework.org/snaphots The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html). |
|
From: <bu...@in...> - 2006-06-02 00:10:36
|
Snapshot has been uploaded to http://www.springframework.org/snaphots The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html). |
|
From: Juergen H. <ju...@in...> - 2006-06-01 19:34:17
|
Well, you got a point there that it's very rare to see both InitializingBean and init-method in use for the same bean. The latter is mainly intended as non-intrusive alternative to the former. That said, I don't really see a strong need to forbid the combo either. After all, Spring's bean init order is not subject for arbitrary change, so the behavior is still absolutely predictable and will remain compatible. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Glen Mazza Sent: Thursday, June 01, 2006 8:21 PM To: spr...@li... Subject: Remove ability to specify init-method for a bean implementing InitializingBean? (Was Re: [Springframework-developer] Spring Framework 2.0 M5 released) Juergen Hoeller wrote: > Dear Spring community, > > I'm pleased to announce that Spring 2.0 M5 has been released. This > intermediate release paves the way for the upcoming release candidate, > giving early access to major new features before the 2.0 API freeze. > Speaking of API freeze, Rob Harrop's Pro Spring book mentions something that might warrant an API change for 2.0. In Ch. 5 -> Bean Lifecycle management -> Hooking into Bean Creation --> Order of Resolution section, he mentions functionality that allows one to specify the "init-method" attribute for a bean that already implements InitializingBean. He writes: "This can be useful if you have an existing bean that performs some initialization in a specific method, but you need to add some more initialization code when you use Spring. However, a better approach is to call your bean's initialization method from afterPropertiesSet(). This way, if Spring changes the initialization order in a future release, your code continues to work as it should." I agree, also I think it is better self-documenting to see (say) initMethod() called directly from afterPropertiesSet() instead of one not calling the other explicitly but just having their ordering specified from the framework. This doesn't seem to be a design that Spring should encourage. I wonder if Spring 2.0 should prohibit specification of an init-method for any class that already implements InitializingBean. (This issue also holds for destroy-method and DisposableBean.) If the purpose of init-method is to provide an ability to initialize classes for which the developer does *not* wish to implement InitializingBean, it seems strange to allow for both to occur. Thanks, Glen ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Glen M. <gr...@ve...> - 2006-06-01 18:22:44
|
Juergen Hoeller wrote: > Dear Spring community, > > I'm pleased to announce that Spring 2.0 M5 has been released. This > intermediate release paves the way for the upcoming release candidate, > giving early access to major new features before the 2.0 API freeze. > Speaking of API freeze, Rob Harrop's Pro Spring book mentions something that might warrant an API change for 2.0. In Ch. 5 -> Bean Lifecycle management -> Hooking into Bean Creation --> Order of Resolution section, he mentions functionality that allows one to specify the "init-method" attribute for a bean that already implements InitializingBean. He writes: "This can be useful if you have an existing bean that performs some initialization in a specific method, but you need to add some more initialization code when you use Spring. However, a better approach is to call your bean's initialization method from afterPropertiesSet(). This way, if Spring changes the initialization order in a future release, your code continues to work as it should." I agree, also I think it is better self-documenting to see (say) initMethod() called directly from afterPropertiesSet() instead of one not calling the other explicitly but just having their ordering specified from the framework. This doesn't seem to be a design that Spring should encourage. I wonder if Spring 2.0 should prohibit specification of an init-method for any class that already implements InitializingBean. (This issue also holds for destroy-method and DisposableBean.) If the purpose of init-method is to provide an ability to initialize classes for which the developer does *not* wish to implement InitializingBean, it seems strange to allow for both to occur. Thanks, Glen |
|
From: <bu...@in...> - 2006-06-01 16:27:38
|
Snapshot has been uploaded to http://static.springframework.org/downloads/nightly/spring-webflow The list of modifications for this build can be found in the build log (http://static.springframework.org/spring-webflow/build/index.html). |
|
From: Juergen H. <ju...@in...> - 2006-06-01 16:00:59
|
Dear Spring community, I'm pleased to announce that Spring 2.0 M5 has been released. This intermediate release paves the way for the upcoming release candidate, giving early access to major new features before the 2.0 API freeze. Spring 2.0 M5 includes reworked scoping support at the bean factory level, support for class instrumentation, updated JPA support, and many further refinements. Furthermore, this release contains numerous fixes for issues discovered since M4. See the changelog for details. Note: Due to an unfortunate issue with the SourceForge file release system, only the "-with-dependencies" download is available immediately. The alternative zip file without dependencies will be added within 24 hours. This release constitutes a feature freeze for the 2.0 target, with the remaining work focussing on documentation, samples, and integration tests. Spring 2.0 RC1 is now just around the corner! Cheers, Juergen ----- Juergen Hoeller Interface21 http://www.springframework.com |
|
From: <bu...@in...> - 2006-06-01 11:36:25
|
Errors and a list of modifications can be found in the build log (http://static.springframework.org/spring/build/index.html). |