springframework-developer — Spring Framework developers list

[Springframework-developer] Quartz support

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

Everybody,
=20
I've revived my Quartz support classes for Spring today. They emerged =
from a job scheduling consulting project I did in autumn 2003. We have =
concrete needs for this now at werk3AT, thus the revival: It's about =
quite simple cron-style scheduling of application jobs.
=20
The basic idea is to set up a Quartz Scheduler via a =
SchedulerFactoryBean, also allowing to register scheduled jobs there via =
a <list> of <refs> to ScheduledJobDefinition beans. A =
ScheduledJobDefinition is just a simple combination of a Quartz =
JobDetail and a Quartz Trigger.
=20
ScheduledJobDefinition bean implementations include:
- DefaultScheduledJobDefinition, allowing to use any implementation of =
Quartz' Job interface with a declaratively configured job data map and =
cron trigger
- MethodInvokingJobDefinition, allowing to specify a method of a =
Spring-managed bean to execute as job (completely declarative, without =
the need for implementing a custom Job object), with a cron trigger.
=20
Both job definition beans can link in a separate Quartz Trigger instance =
instead of a cron expression; DefaultScheduledJobDefinition can also =
link in a separate Quartz JobDetail instance instead of a job class.
=20
That's all there is: A simple declarative way of using Quartz within =
Spring. Typically no rescheduling or the like: All schedules are set up =
on context startup, defined as bean definitions. Of course, you can also =
fetch the Scheduler instance and perform any custom scheduling, instead =
of using preconfigured ScheduledJobDefinition beans.
=20
The typical usage scenario are low-level jobs within an application, =
like data synchronization or storage cleanup - all predefined jobs that =
are just customized by an administrator. Fits nicely into Spring's =
application context model; most jobs will simply delegate to =
Spring-managed business objects.
=20
I expect to have this polished by the end of the week, as we need it at =
werk3AT quite urgently. I'd like to include this already in Spring 1.0 =
final, as it's just 6 pretty simple classes (yes, I know - feature =
freeze - never mind ;-). The main question is where to put it: I suggest =
"org.springframework.scheduling.quartz".
=20
If there are no general objections, I'll commit it by the end of this =
week, for review within the next week - still plenty of time before 1.0 =
final ;-) Looking forward to your feedback!=20
=20
Juergen
=20

Re: [Springframework-developer] SqlQueryTestSuite is broken on my system

[<tri...@tr...>]

It was because cglib/asm.jar was missing from the classpath.  I have added it to
the '.classpath' file in CVS.

I now get the "green bar" in 81 seconds on a PIII 800MHz - not bad.

Thomas


Quoting Rod Johnson <rod...@in...>:

> > - Running the entire test suite in Eclipse JUnit no longer runs without
> > errors (got 99 last run)
> 
> I think we should fix this as a priority. It takes < 1 min on my laptop to
> run all tests in Eclipse.
> 
> Must be a side effect.
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] flexible configuration schemas (beyond javabeans)

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

Keith, I like this proposal. It would seem like these different
config approaches could just be add-ons as different
implementations of BeanFactory and/or ApplicationContext. 

I still use Webwork 1.4, partially because of its simple
configuration, and I actually still use the properties file. I
don't mind XML, but sometimes a properties file can be just as
easy to understand and less typing. Your example below could
become:

myValidateableBean.class=com.MyValidateableBean
myValidateableBean.validateableProperty.continueOnError=false
myValidateableBean.validateableProperty.mandatory=true
myValidateableBean.validateableProperty.maxLength=25
myValidateableBean.validateableProperty.uniqueName=true

which might actually be more typing than XML because of the
long-ish bean name and property name, but it'd just be an
option. As you mention, the work would be in building the
processing code to read in the configuration.

I think Rod's original J2EE book introduced the BeanFactory
concept and used properties as an example of configuration. I
believe properties are still supported, but not to the extent
that XmlBeanFactory is supported.

But anyways, perhaps a "contrib" module for Spring would be good
for alternate forms of configuration. I don't have any
objections to the current XmlBeanFactory, but there are probably
situations where the configuration could be a little more
simple.

Rob



---- On Wed, 18 Feb 2004, Keith Donald (kd...@cs...)
wrote:

> <validator class="com.MyValidateableBean"
objectName="myValidateableBean">
>     <property name="validateableProperty"
continueOnError="false">
>         <rule type="mandatory"/>
>         <rule type="maxLength"/>
>             <parameter name="value" value="25"/>
>         </rule>
>         <rule type="uniqueName"/>
>     </property>
> </validator>
>

Re: [Springframework-developer] SqlQueryTestSuite is broken on my system

[Rod J. <rod...@in...>]

> - Running the entire test suite in Eclipse JUnit no longer runs without
> errors (got 99 last run)

I think we should fix this as a priority. It takes < 1 min on my laptop to
run all tests in Eclipse.

Must be a side effect.

Re: [Springframework-developer] Simpler Web MVC Configuration Proposal

[Lars F. <lar...@gm...>]

This is one thing I mentioned before, it's too complicated to get
started with Spring MVC. Maybe it's better to concentrate on
integration of existing frameworks.

Regards,
Lars

> I have previously developed web applications using WebWork (1 & 2), and I
> have been drawn to the Spring Framework because of its complete IOC
> support
> and more so, its excellent data abstraction layer. Particularly of
> interest
> to me on my current project is its Hibernate support and Transaction
> capabilities.
> 
> At the moment however, I am focused on some of the web tier architecture.
> It
> may not be for everyone, but I find myself longing for WebWork's simple
> configuration of the web tier. I realize that I could integrate Spring and
> WebWork and be done with it, but I don't use WebWork's taglib, nor do I
> want
> to introduce another dependency if I don't have to. Right now, I am trying
> to get Spring's web MVC framework sorted out. I apologize in advance if I
> misstate any facts or statements regarding the Spring Framework's
> capabilities or implementation. I am a Spring-chicken at the moment. :-)
> 
> I think I understand the various mapping files that must be configured,
> and
> the two, three, or twelve optional variants of each. As I was going
> through
> each of the classes that provide a view resolver (InternalViewResolver,
> ResourceBundleViewResolver and XmlViewResolver), I began to wonder if I
> was
> the only person who would like a simplified configuration. I think the
> primary differentiation when comparing Spring or WebWork on the Web-tier
> alone, is WebWork's simpler and more cohesive configuration file. I don't
> think either framework's WEB MVC configuration provides any more general
> functionality than the other, but I would like an optional resolver class
> that allows a single configuration file to specify the Controllers, URL
> Mapping, View Resolvers and the parameters that each may take. I don't
> think
> this would be difficult either because of Spring's pluggability.
> 
> In Spring, in order to use a single controller I have to configure the:
> 
> viewResolver / instance of ResourceBundleViewResolver, XmlViewResolver, 
>                or InternalViewResolver.
> 
>     Used by the dispatcher servlet to resolve the ModelAndView's view 
>     name (and locale) to a View class.
> 
>     This object is retrieved "by name" by the dispatcher servlet, hence 
>     there is only one per servlet context.
> 
> handlerMapping / instance of BeanNameUrlHandlerMapping or 
>                  SimpleUrlHandlerMapping.
> 
>     Used by the dispatcher to 
> 
>     There can be many url handlers in a single servlet context since the 
>     dispatcher servlet searches for bean's in its context that implement 
>     the HandlerMapping interface. They can also be sorted in order to 
>     give one handler priority over another when there is a URL that 
>     matches multiple HandlerMappings.
>     
> controller / instance of the Controller interface. There are a bunch of 
>              these, and this probably represents one of the more 
>              confusing aspects of Spring.
>     
>     Each controller provides different functionality from the next, but
>     it seems like the design suffers a bit here. For example, 
>     AbstractController is extended by MultiActionController,
>     BaseCommandController and ParameterizableViewController. Since a
>     controller must pick a single subclass to extend, a developer can
>     only take advantage of the benefits of one of these controllers. I
>     preferred WebWork's use of interfaces (and IOC) to drive the capabi-
>     lities of the Controller. This a moot point however, since I am only 
>     focused on configuration at the moment.
> 
> Each of these three configuration areas (four if you count
> ExceptionResolvers, five if you count HandlerAdapters, etc.) are powerful
> in
> their flexibility, but somewhat cumbersome for someone coming from WebWork
> (or Maverick). For many of us a simpler configuration would be a welcome
> augmentation to Spring, and because of Spring's configuration flexibility,
> I
> don't imagine it would take away from any features.
> 
> As an example for configuration, consider the following sample from the
> petclinic example application that ships with Spring.
> 
> -----------------------------------------------------------------------
> 
> petclinic-servlet.xml
> =====================
> <bean id="viewResolver"
> class="org.springframework.web.servlet.view.ResourceBundleViewResolver">
> 	<property name="basename"><value>views</value></property>
> </bean>
> 
> <bean id="urlMapping"
> class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
> 	<property name="mappings">
> 		<props>
> 			<prop key="/welcome.htm">clinicController</prop>
> 		</props>
> 	</property>
> </bean>
> 
> <bean id="clinicController"
> class="org.springframework.samples.petclinic.web.ClinicController">
> 	<property name="methodNameResolver">
> 		<ref local="clinicControllerResolver"/>
> 	</property>
> 	<property name="clinic">
> 		<ref bean="clinic"/>
> 	</property>
> </bean>
> 
> <bean id="clinicControllerResolver"
> 	
>
class="org.springframework.web.servlet.mvc.multiaction.PropertiesMethodNameR
> esolver">
> 	<property name="mappings">
> 		<props>
> 			<prop key="/welcome.htm">welcomeHandler</prop>
> 		</props>
> 	</property>
> </bean>
> 
> views.properties
> ================
> 
> welcomeView.class=org.springframework.web.servlet.view.JstlView
> welcomeView.url=/WEB-INF/jsp/welcome.jsp
> 
> -----------------------------------------------------------------------
> 
> This is a lot of configuration information when compared to a similar
> WebWork configuration. It also is spread across two files, although I
> suppose that there is a Spring technique to declare viewResolver data in
> the
> petclinic-servlet.xml file, perhaps by using an XmlViewResolver and
> embedding the XML data as an IOC property? Another unclear step is the
> knowledge the developer must possess that his
> ClinicController.welcomeHandler() method returns the view mapping named
> 'welcomeView'. It is this name that is looked up in the views.properties
> file. This is somewhat unintuitive and other examples have tried to combat
> this ambiguity by including the view mappings directly (sort of) in the
> Controller configuration.
> 
> <bean id="findOwnersForm" 
> 	class="org.springframework.samples.petclinic.web.FindOwnersForm">
> 	<property name="formView"><value>findOwnersForm</value></property>
> 	<property
> name="selectView"><value>selectOwnerView</value></property>
> 	<property name="successView"><value>ownerRedirect</value></property>
> </bean>
> 
> This example demonstrates something us WebWork developers have used very
> effectively for some time. The view is always returned as a simple string
> in
> WebWork and this maps to the actual view via configuration information.
> The
> same thing is occurring in the Spring example, but in a slightly
> backhanded
> way. The SimpleFormController defines formView and successView as String
> properties. If the controller completes successfully, it returns
> getSuccessView() as its view and this in turn returns 'ownerRefirect' as
> the
> mapped view. The developer also introduced a new view result called
> 'selectView'. In order to support this new result view, the developer has
> to
> implement the selectView property in their subclass. Very cumbersome when
> compared to WebWork's "always map" approach to view results.
> 
> Thanks for sticking with this unintentionally long post. I guess I set all
> of this up to suggest an alternative approach to configuring Spring's web
> MVC that is more compact and easier for new developers. It is based
> heavily
> on WebWork's configuration, so it should prove even easier for WebWork
> developers to migrate. I do realize that this configuration will ruffle
> the
> feathers of some architects that laud Spring's separation of components,
> but
> I appreciate the fact that a configuration change does not necessarily
> negate an architecture. In fact it is a testament to Spring's solid
> architecture that such a configuration may be made possible without
> changing
> any of Spring's infrastructure.
> 
> proposed configuration - controller.xml
> ==============================================
> 
> <controller alias="/welcome.htm" 
> 	class="org.springframework.samples.petclinic.web.ClinicController" 
> 	method="welcomeHandler">
> 	<property name="clinic"><ref bean="clinic"/></property>
> 	<results>
> 		<result name="selectView" 
> 	
> class="org.springframework.web.servlet.view.JstlView" 
> 			url="/WEB-INF/jsp/welcome.jsp" />
> 		<result name="successView" 
> 	
> class="org.springframework.web.servlet.view.RedirectView" 
> 			url="owner.htm" />
> 	</results>
> </controller>
> 
> These seven lines in a single file represent all of the configuration
> information found in the prior 23 lines spread across a couple files.
> There
> are probably other Spring capabilities that I am not representing here in
> this small example, but this is at least 95 percent of the types of web
> controllers that I use. I also am not showing the new configuration bean
> that would have to be configured in the xxx-servlet.xml file.
> 
> I believe this configuration data should exist in the xxx-servlet.xml file
> or loadable from a separate file. No matter where it exists, it should be
> loadable as an applicationContext object with full Spring IOC capability,
> including parameter substitution.
> 
> If I was going to approach writing this new configuration support bean I
> would create a configuration bean that can read in the controller.xml file
> in a Spring IOC manner. I guess I would base this work on XmlViewResolver,
> although I am unsure if this includes all of the IOC benefits
> automatically?
> 
> <bean id="viewResolver" 
> 	class="org.springframework.web.servlet.mvc.ControllerConfig">
> 	<property name="location">
> 		<value>/WEB-INF/controller.xml</value>
> 	</property>
> </bean>
> 
> I would have to give the bean an id of "viewResolver" because that is the
> only property that the dispatcher loads by name. The dispatcher discovers
> the other configuration parameters by searching for interface
> implementations amongst all the configured beans.
> 
> So org.springframework.web.servlet.mvc.ControllerConfig would read the
> controller.xml file and implement the following interfaces:
> 	- org.springframework.web.servlet.ViewResolver
> 	- org.springframework.web.servlet.HandlerExceptionResolver
> 	- org.springframework.web.servlet.HandlerMapping
> 	
> I'm not sure what the best approach for loading the XML configuration file
> is to get Spring's IOC support, including external bean references from
> the
> applicationContext and servletContexts. Also it should be reloadable
> during
> development through the use of a flag. Any ideas on where to start with
> that?
> 	
> Once the configuration is loaded, it seems like the interface
> implementations would be straightforward.	
> 
> Thanks for reading this far. Hopefully it wasn't a waste of your time!	
> - jim cook
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

[Springframework-developer] flexible configuration schemas (beyond javabeans)

[Keith D. <kd...@cs...>]

A recent post to the user list got me thinking about an idea for extending
Springs support for configuration beyond that of java beans in certain,
frequently-used circumstances with the goals of:
    1. Reducing configuration complexity by requiring less configuration XML
overall.
    2. Tailoring a custom configuration schema to a specific problem domain,
making the XML 'easier to understand' and more abstract (perhaps by allowing
the creation of a xml schema definition.)

What I am suggesting is something similiar to how Eclipse -- and now
Hivemind -- does it.  In the post I am referring to the Spring-webmvc
developer wanted to simplify configuration information for his web
controllers to in effect make the configuration xml look a lot like
WebWorks.  I've found in developing a data validation framework for
rich-clients I would also like a similiar flexible xml-schema capability,
because I could simplify what the user needs to fool with in order to
define/tweak validation rules.

I know all this may sound a bit abstract so I'll try to illustrate what I'm
talking about with an example--here's how the definition of a set of data
validation rules for a bean class looks with Spring today:

Note: what this configuration says is "for instances of
"MyValidateableBean", apply a <mandatory>, <maxlength>, and <uniqueName>
rule to the 'name' property."

 <bean id="myValidateableBean"
class="com.csi.commons.utils.validator.BeanValidatorImpl">
     <property
name="beanClass"><value>com.MyValidateableBean</value></property>
     <property
name="objectName"><value>myValidateableBean</value></property>
     <property name="propertyValidators">
         <set>
              <bean id="validateableProperty"
class="com.csi.commons.utils.validator.PropertyValidatorImpl">
                  <constructor-arg index="0">
                        <description>The name of the property with
validation rules attached</description>
                        <value>validateableProperty</value>
                  </constructor-arg>
                  <constructor-arg index="1">
                        <description>The validation rules for this
property</description>
                       <set>
                             <ref bean="mandatory"/>
                             <bean id="nameMaxLength"
class="com.csi.commons.utils.validator.MaxLengthValidationRule">
                                  <constructor-arg
index="0">25</constructor-arg>
                             </bean>
                             <ref bean="uniqueName"/>
                       </set>
                   </constructor-arg>
                  <property
name="continueOnError"><value>false</value></property>
               </bean>
         </set>
     </property>
 </bean>

A couple of things--obviously the XML is littered with property, set,
constructor-arg, and class declarations, which bloats the XML and couples
configuration with implementation.  Don't get me wrong, I very much like
javabeans-based configuration because it's so generically flexible (and
quite powerful), but in some cases I would love to be able to simplify the
xml schema for validation because these validation rules are frequently
defined and might be tweaked by end users.  Here's how I'd like it to look
(this configuration schema would scream):

<validator class="com.MyValidateableBean" objectName="myValidateableBean">
    <property name="validateableProperty" continueOnError="false">
        <rule type="mandatory"/>
        <rule type="maxLength"/>
            <parameter name="value" value="25"/>
        </rule>
        <rule type="uniqueName"/>
    </property>
</validator>

Much less xml.  No constructor/set/class references.  All that is abstracted
away and what remains is just configuration information.

Now, to support this you'd need:
    1. An xml schema definition so the XML could be validated.
    2. A way to map the XML above into some generic java
ConfigurationElements that could then be processed by code that would then
instantiate what is basically declared in the first 'Spring today'
definition above.  For example, rule "type" strings above would needed to be
mapped to classes using a RuleFactory or something.

Basically complexity is pushed into custom processing code at the gain of
greatly simplifying the XML for the configuring user.  Again this is very
similiar to how Eclipe's plugin model -- and now Hivemind -- works.

What do you guys think?

Keith

Re: [Springframework-developer] SqlQueryTestSuite is broken on my system

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

Colin,

I modifed JdbcTemplate and that broke this test - it's now fixed.

This brings up a couple of issues for out test suite:

- Running the entire test suite in Eclipse JUnit no longer runs without 
errors (got 99 last run)
- Running the tests with Ant takes 4-5 minutes on my laptop
- A single package test usually works fine in Eclipse JUnit, but that 
does not detect cross package dependencies
- EasyMock doesn't excatly give you a good idea of what the issue is
- Should the jdbc.object test suite mock JdbcTemplate instead of mocking 
the JDBC classes - that way a change to the internal implementation of 
JdbcTemplate would not throw off other tests.

Thomas


Colin Sampaleanu wrote:

> Testsuite: org.springframework.jdbc.object.SqlQueryTestSuite
> Tests run: 4, Failures: 1, Errors: 0, Time elapsed: 1.282 sec
> ------------- Standard Output ---------------
> 2004-02-17 23:12:05,937 WARN 
> org.springframework.jdbc.support.SQLErrorCodesFactory - Null meta data 
> from connection when trying to create exception translator
> 2004-02-17 23:12:05,968 WARN 
> org.springframework.jdbc.support.SQLErrorCodesFactory - Null meta data 
> from connection when trying to create exception translator
> 2004-02-17 23:12:05,968 WARN 
> org.springframework.jdbc.support.SQLErrorCodesFactory - Null meta data 
> from connection when trying to create exception translator
> 2004-02-17 23:12:05,984 WARN 
> org.springframework.jdbc.support.SQLErrorCodesFactory - Null meta data 
> from connection when trying to create exception translator
> 2004-02-17 23:12:05,984 WARN 
> org.springframework.jdbc.support.SQLErrorCodesFactory - Null meta data 
> from connection when trying to create exception translator
> ------------- ---------------- ---------------
>
> Testcase: testQueryWithoutParams took 1.25 sec
> Testcase: testQueryWithoutEnoughParams took 0 sec
> Testcase: testBindVariableCountWrong took 0 sec
> Testcase: testStringQueryWithResults took 0.032 sec
>    FAILED
>
>  Expectation failure on verify:
>    prepareStatement("SELECT COUNT(FORENAME) FROM CUSTMR WHERE 
> FORENAME='beta'"): expected: 1, actual: 0
>    prepareStatement("SELECT COUNT(FORENAME) FROM CUSTMR WHERE 
> FORENAME='charlie'"): expected: 1, actual: 0
> junit.framework.AssertionFailedError:
>  Expectation failure on verify:
>    prepareStatement("SELECT COUNT(FORENAME) FROM CUSTMR WHERE 
> FORENAME='beta'"): expected: 1, actual: 0
>    prepareStatement("SELECT COUNT(FORENAME) FROM CUSTMR WHERE 
> FORENAME='charlie'"): expected: 1, actual: 0
>    at 
> org.easymock.internal.AbstractBehavior.verify(AbstractBehavior.java:77)
>    at org.easymock.internal.PlayState.verify(PlayState.java:25)
>    at org.easymock.MockControl.verify(MockControl.java:188)
>    at 
> org.springframework.jdbc.JdbcTestCase.tearDown(JdbcTestCase.java:79)
>    at 
> org.springframework.jdbc.object.SqlQueryTestSuite.tearDown(SqlQueryTestSuite.java:54) 
>
>
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>

Re: [Springframework-developer] DTD versioning

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

Personally I'd rather get a version number in there from the get-go, 
especially given that we've already had a few variants. I also have no 
problem with the possibility that some future release (e.g. 1.2) ships 
with a DTD which has an unchanged version number (e.g. 1.0). I consider 
it a DTD version, whos primary goal is to indicate a change from one DTD 
to another. Of course if something does change in the DTD so you change 
the DTD number for another version of the DTD, it makes sense to make 
the new version the same as the Spring version which introduces the change.

But the only thing I feel pretty strongly about is chaning the version 
in the name when something actually changes, so if other people just 
want to leave the name as-is for now, I have no real objections...

jürgen höller [werk3AT] wrote:

>I actually prefer the Hibernate style "spring-beans-1.0.dtd", as it seems more natural to me. After all, underscores look like a workaround for filesystems that can't handle dots in filenames.
>
>An interesting point is that it could well be that our bean definition format won't change for the next couple of Spring releases. All the new features that we plan to introduce are achievable with the current generic format. So if we recommend a versioned DTD, we have to assume that the "spring-beans-1.0.dtd" reference will be in use for Spring 1.1/1.2/etc too, arguably looking a bit odd.
>
>Hibernate is also a bit weird in that respect: "hibernate-mapping-2.0.dtd" was modified for 2.1 but still kept the 2.0 DTD version number... Noone complained, so I guess most people are fine with DTDs that aren't versioned (respectively not versioned in a fine-grained version).
>
>So a further option for us would be to stay with "spring-beans.dtd" for as long as there aren't any significant changes in the DTD. Of course, we would allow "spring-beans.dtd" as shortcut anyway, always defaulting to the most current DTD. The question is rather: What DTD name to we *recommend* to use - explicit version or not? Consequently, what DTD name will our sample apps use?
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Tuesday, February 17, 2004 2:12 PM
>To: spr...@li...
>Subject: Re: Re [Springframework-developer] DTD versioning
>
>
>I am ok with either one. I picked the variant I did before because it is 
>what Sun uses, but if somebody likes the Hibernate-style better I am ok 
>with that.
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Any opinions on the exact naming of the DTD file? I'd like to commit the change promptly :-)
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
>>Gesendet: Mo 16.02.2004 08:40
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] DTD versioning
>>
>>
>>
>>Colin, Rod,
>>
>>I've just adapted BeansDtdResolver to fall back to the default DTD file "spring-beans_1_0.dtd" if  "spring-beans.dtd" was specified, issuing a corresponding message at INFO level (not committed yet). I guess INFO is appropriate, as "spring-beans" can simply be considered a shortcut for "spring-beans_1_0" for the time being.
>>
>>If we agree on the exact naming that Colin proposed, I'll commit this and adapt all our bean definition declarations in the samples etc. The only alternative that I see is "spring-beans-1.0.dtd" as used by Hibernate's DTDs, while "_1_0" is the style used by Sun's DTDs.
>>
>>IMO, "spring-beans.dtd" should also stay available from the website, simply adding the versioned DTD file there.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von Rod Johnson
>>Gesendet: So 15.02.2004 17:18
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] DTD versioning
>>
>>
>>
>>Colin
>>
>>I agree about versioning, so long as we can avoid breaking people's
>>definitions. We could have only the new URL on the web site and modify the
>>entity resolver so that it produces a log warning on finding the old one
>>(but still resolved it). This should provide a deprecation-style upgrade
>>path.
>>
>>Regards,
>>Rod
>>
>>----- Original Message -----
>>From: "Colin Sampaleanu" <col...@ex...>
>>To: <spr...@li...>
>>Sent: Sunday, February 15, 2004 3:26 PM
>>Subject: [Springframework-developer] DTD versioning
>>
>>
>> 
>>
>>    
>>
>>>I updated the DTD on the website, and this reminds me that we should
>>>version the document. I propose naming it something like
>>>
>>>spring-beans_1_0.dtd
>>>
>>>with the doctype definition being:
>>>
>>><!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 1.0//EN"
>>>       "http://www.springframework.org/dtd/spring-beans_1_0.dtd">
>>>
>>>If everyone is in agreement, the only question is if we should keep the
>>>old one around (ie keep both versions) for the 1.0 release. I would
>>>favour having only the new version, to avoid future confusion, although
>>>this would force everybody to update their definition documents.
>>>
>>>Regards,
>>>Colin
>>>
>>>      
>>>

Re: [Springframework-developer] DTD versioning

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

I actually prefer the Hibernate style "spring-beans-1.0.dtd", as it =
seems more natural to me. After all, underscores look like a workaround =
for filesystems that can't handle dots in filenames.

An interesting point is that it could well be that our bean definition =
format won't change for the next couple of Spring releases. All the new =
features that we plan to introduce are achievable with the current =
generic format. So if we recommend a versioned DTD, we have to assume =
that the "spring-beans-1.0.dtd" reference will be in use for Spring =
1.1/1.2/etc too, arguably looking a bit odd.

Hibernate is also a bit weird in that respect: =
"hibernate-mapping-2.0.dtd" was modified for 2.1 but still kept the 2.0 =
DTD version number... Noone complained, so I guess most people are fine =
with DTDs that aren't versioned (respectively not versioned in a =
fine-grained version).

So a further option for us would be to stay with "spring-beans.dtd" for =
as long as there aren't any significant changes in the DTD. Of course, =
we would allow "spring-beans.dtd" as shortcut anyway, always defaulting =
to the most current DTD. The question is rather: What DTD name to we =
*recommend* to use - explicit version or not? Consequently, what DTD =
name will our sample apps use?

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Tuesday, February 17, 2004 2:12 PM
To: spr...@li...
Subject: Re: Re [Springframework-developer] DTD versioning


I am ok with either one. I picked the variant I did before because it is =

what Sun uses, but if somebody likes the Hibernate-style better I am ok=20
with that.

j=FCrgen h=F6ller [werk3AT] wrote:

>Any opinions on the exact naming of the DTD file? I'd like to commit =
the change promptly :-)
>=20
>Juergen
>=20
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
>Gesendet: Mo 16.02.2004 08:40
>An: spr...@li...
>Betreff: Re: [Springframework-developer] DTD versioning
>
>
>
>Colin, Rod,
>
>I've just adapted BeansDtdResolver to fall back to the default DTD file =
"spring-beans_1_0.dtd" if  "spring-beans.dtd" was specified, issuing a =
corresponding message at INFO level (not committed yet). I guess INFO is =
appropriate, as "spring-beans" can simply be considered a shortcut for =
"spring-beans_1_0" for the time being.
>
>If we agree on the exact naming that Colin proposed, I'll commit this =
and adapt all our bean definition declarations in the samples etc. The =
only alternative that I see is "spring-beans-1.0.dtd" as used by =
Hibernate's DTDs, while "_1_0" is the style used by Sun's DTDs.
>
>IMO, "spring-beans.dtd" should also stay available from the website, =
simply adding the versioned DTD file there.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von Rod Johnson
>Gesendet: So 15.02.2004 17:18
>An: spr...@li...
>Betreff: Re: [Springframework-developer] DTD versioning
>
>
>
>Colin
>
>I agree about versioning, so long as we can avoid breaking people's
>definitions. We could have only the new URL on the web site and modify =
the
>entity resolver so that it produces a log warning on finding the old =
one
>(but still resolved it). This should provide a deprecation-style =
upgrade
>path.
>
>Regards,
>Rod
>
>----- Original Message -----
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Sunday, February 15, 2004 3:26 PM
>Subject: [Springframework-developer] DTD versioning
>
>
> =20
>
>>I updated the DTD on the website, and this reminds me that we should
>>version the document. I propose naming it something like
>>
>>spring-beans_1_0.dtd
>>
>>with the doctype definition being:
>>
>><!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 1.0//EN"
>>        "http://www.springframework.org/dtd/spring-beans_1_0.dtd">
>>
>>If everyone is in agreement, the only question is if we should keep =
the
>>old one around (ie keep both versions) for the 1.0 release. I would
>>favour having only the new version, to avoid future confusion, =
although
>>this would force everybody to update their definition documents.
>>
>>Regards,
>>Colin
>>
>>
>>
>>
>>-------------------------------------------------------
>>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>>Build and deploy apps & Web services for Linux with
>>a free DVD software kit from IBM. Click Now!
>>http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>   =20
>>
>
>
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
> =20
>




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Re: [springframework - Open Discussion] Two feature requests

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

Okidoki, if there aren't any strongly positive replies, I consider this =
turned down.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Wednesday, February 18, 2004 8:01 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests


I'm against this. People should use XML editors, so typing is =
irrelevant.
And we shouldn't add "conveniences" that we wouldn't use ourselves.

Messing up our XML format may hurt us in future. For example, we should
probably add an XSLT stylesheet to generate pretty doco of bean =
definition
files. This gets a bit harder with such blurring.

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Tuesday, February 17, 2004 11:23 PM
Subject: Re: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests


> It doesn't feel incredibly clean to me, but I am not opposed to adding
> it. My one concern would be if this constrained us somehow for future
> enhancements, but I can't think of any issues right now...
>
>
> j=FCrgen h=F6ller [werk3AT] wrote:
>
> >I'd like to hear further opinions on this... Does anyone strongly =
object
to adding that shortcut style as option? Anyone actually preferring the
shortcut style? I wouldn't use it myself, but I don't mind the option.
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: spr...@li... im Auftrag =
von
Rod Johnson
> >Gesendet: Di 17.02.2004 22:50
> >An: spr...@li...
> >Betreff: Re: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests
> >
> >
> >
> >Well if it's backward compatible... But I don't think we should =
advocate
> >this.
> >
> >----- Original Message -----
> >From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> >To: <spr...@li...>
> >Sent: Tuesday, February 17, 2004 7:10 PM
> >Subject: [Springframework-developer] Re: [springframework - Open
Discussion]
> >Two feature requests
> >
> >
> >Actually, this is extremely easy to implement: I've just adapted
> >DefaultXmlBeanDefinitionParser and it works nicely, still allowing =
for
> ><value> tags but also for text values as CDATA...
> >
> >Of course, I do appreciate the explicit notion of a value, but I =
guess we
> >should allow for this shortcut style too - we shouldn't force people =
into
a
> >certain style here.
> >
> >If noone objects, I'll commit this promptly.
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: j=FCrgen h=F6ller [werk3AT]
> >Gesendet: Di 17.02.2004 20:02
> >An: spr...@li...
> >Betreff: Fw: [springframework - Open Discussion] Two feature requests
> >
> >
> >Any thoughts on suggestion number 2? As I wrote in that forum, I've
> >considered that myself repeatedly...
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: SourceForge.net [mailto:no...@so...]
> >Gesendet: Mo 16.02.2004 18:10
> >An: no...@so...
> >Betreff: [springframework - Open Discussion] Two feature requests
> >
> >
> >
> >
> >Read and respond to this message at:
> >https://sourceforge.net/forum/message.php?msg_id=3D2425898
> >By: aaron
> >
> >Since there are no trackers...
> >
> >I have two feature requests, and some comments
> >
> >1) Add a default attribute to the ParameterMethodNameResolver.
Currently,
> >if
> >the parameter is not present, this resolver just bombs all over... =
Having
a
> >default would be trivial to implement and allow the developer to let =
the
> >application
> >proceed when a parameter was not provided (no reason to pollute the =
GET
url)
> >
> >2) This might be a religious issue, but it would be very convenient =
if
> >the requirement of using a nested <value> element in <property> =
elements,
> >for
> >values was lifted.  Either there is CDATA (in which case we assume =
it's a
> >literal
> >value), or there are nested elements.  Having both could simply =
result in
a
> >configuration error.  This would save typing and lots of cumbersome
errors
> >relating
> >to not including the nested <value> element.  Also, some docs give
examples
> >with literals without this <value> element.
> >
> >The other things I've run into is: in mapping handlers, although you =
can
> >inspect
> >the request and response arguments, you cannot rewrite them (since =
the
> >interfaces
> >do not provide mutators).  This makes using request wrappers =
impossible.
I
> >suggest another form of method signature for handlers which take =
objects
> >which
> >hold a reference to HttpServletRequest and HttpServletResponse
respectively,
> >instead of having those objects as direct, immutable arguments.
> >
> >To get around this I have overridden a handleRequestInternal method =
in my
> >controller
> >and just call super.handleRequestInternal giving it
> >my HttpServletRequestWrapper.
> >
> >
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: [springframework - Open Discussion] Two feature requests

[Rod J. <rod...@in...>]

I'm against this. People should use XML editors, so typing is irrelevant.
And we shouldn't add "conveniences" that we wouldn't use ourselves.

Messing up our XML format may hurt us in future. For example, we should
probably add an XSLT stylesheet to generate pretty doco of bean definitio=
n
files. This gets a bit harder with such blurring.

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Tuesday, February 17, 2004 11:23 PM
Subject: Re: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests


> It doesn't feel incredibly clean to me, but I am not opposed to adding
> it. My one concern would be if this constrained us somehow for future
> enhancements, but I can't think of any issues right now...
>
>
> j=FCrgen h=F6ller [werk3AT] wrote:
>
> >I'd like to hear further opinions on this... Does anyone strongly obje=
ct
to adding that shortcut style as option? Anyone actually preferring the
shortcut style? I wouldn't use it myself, but I don't mind the option.
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: spr...@li... im Auftrag =
von
Rod Johnson
> >Gesendet: Di 17.02.2004 22:50
> >An: spr...@li...
> >Betreff: Re: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests
> >
> >
> >
> >Well if it's backward compatible... But I don't think we should advoca=
te
> >this.
> >
> >----- Original Message -----
> >From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> >To: <spr...@li...>
> >Sent: Tuesday, February 17, 2004 7:10 PM
> >Subject: [Springframework-developer] Re: [springframework - Open
Discussion]
> >Two feature requests
> >
> >
> >Actually, this is extremely easy to implement: I've just adapted
> >DefaultXmlBeanDefinitionParser and it works nicely, still allowing for
> ><value> tags but also for text values as CDATA...
> >
> >Of course, I do appreciate the explicit notion of a value, but I guess=
 we
> >should allow for this shortcut style too - we shouldn't force people i=
nto
a
> >certain style here.
> >
> >If noone objects, I'll commit this promptly.
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: j=FCrgen h=F6ller [werk3AT]
> >Gesendet: Di 17.02.2004 20:02
> >An: spr...@li...
> >Betreff: Fw: [springframework - Open Discussion] Two feature requests
> >
> >
> >Any thoughts on suggestion number 2? As I wrote in that forum, I've
> >considered that myself repeatedly...
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: SourceForge.net [mailto:no...@so...]
> >Gesendet: Mo 16.02.2004 18:10
> >An: no...@so...
> >Betreff: [springframework - Open Discussion] Two feature requests
> >
> >
> >
> >
> >Read and respond to this message at:
> >https://sourceforge.net/forum/message.php?msg_id=3D2425898
> >By: aaron
> >
> >Since there are no trackers...
> >
> >I have two feature requests, and some comments
> >
> >1) Add a default attribute to the ParameterMethodNameResolver.
Currently,
> >if
> >the parameter is not present, this resolver just bombs all over... Hav=
ing
a
> >default would be trivial to implement and allow the developer to let t=
he
> >application
> >proceed when a parameter was not provided (no reason to pollute the GE=
T
url)
> >
> >2) This might be a religious issue, but it would be very convenient if
> >the requirement of using a nested <value> element in <property> elemen=
ts,
> >for
> >values was lifted.  Either there is CDATA (in which case we assume it'=
s a
> >literal
> >value), or there are nested elements.  Having both could simply result=
 in
a
> >configuration error.  This would save typing and lots of cumbersome
errors
> >relating
> >to not including the nested <value> element.  Also, some docs give
examples
> >with literals without this <value> element.
> >
> >The other things I've run into is: in mapping handlers, although you c=
an
> >inspect
> >the request and response arguments, you cannot rewrite them (since the
> >interfaces
> >do not provide mutators).  This makes using request wrappers impossibl=
e.
I
> >suggest another form of method signature for handlers which take objec=
ts
> >which
> >hold a reference to HttpServletRequest and HttpServletResponse
respectively,
> >instead of having those objects as direct, immutable arguments.
> >
> >To get around this I have overridden a handleRequestInternal method in=
 my
> >controller
> >and just call super.handleRequestInternal giving it
> >my HttpServletRequestWrapper.
> >
> >
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] SqlQueryTestSuite is broken on my system

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

Testsuite: org.springframework.jdbc.object.SqlQueryTestSuite
Tests run: 4, Failures: 1, Errors: 0, Time elapsed: 1.282 sec
------------- Standard Output ---------------
2004-02-17 23:12:05,937 WARN 
org.springframework.jdbc.support.SQLErrorCodesFactory - Null meta data 
from connection when trying to create exception translator
2004-02-17 23:12:05,968 WARN 
org.springframework.jdbc.support.SQLErrorCodesFactory - Null meta data 
from connection when trying to create exception translator
2004-02-17 23:12:05,968 WARN 
org.springframework.jdbc.support.SQLErrorCodesFactory - Null meta data 
from connection when trying to create exception translator
2004-02-17 23:12:05,984 WARN 
org.springframework.jdbc.support.SQLErrorCodesFactory - Null meta data 
from connection when trying to create exception translator
2004-02-17 23:12:05,984 WARN 
org.springframework.jdbc.support.SQLErrorCodesFactory - Null meta data 
from connection when trying to create exception translator
------------- ---------------- ---------------

Testcase: testQueryWithoutParams took 1.25 sec
Testcase: testQueryWithoutEnoughParams took 0 sec
Testcase: testBindVariableCountWrong took 0 sec
Testcase: testStringQueryWithResults took 0.032 sec
    FAILED

  Expectation failure on verify:
    prepareStatement("SELECT COUNT(FORENAME) FROM CUSTMR WHERE 
FORENAME='beta'"): expected: 1, actual: 0
    prepareStatement("SELECT COUNT(FORENAME) FROM CUSTMR WHERE 
FORENAME='charlie'"): expected: 1, actual: 0
junit.framework.AssertionFailedError:
  Expectation failure on verify:
    prepareStatement("SELECT COUNT(FORENAME) FROM CUSTMR WHERE 
FORENAME='beta'"): expected: 1, actual: 0
    prepareStatement("SELECT COUNT(FORENAME) FROM CUSTMR WHERE 
FORENAME='charlie'"): expected: 1, actual: 0
    at 
org.easymock.internal.AbstractBehavior.verify(AbstractBehavior.java:77)
    at org.easymock.internal.PlayState.verify(PlayState.java:25)
    at org.easymock.MockControl.verify(MockControl.java:188)
    at org.springframework.jdbc.JdbcTestCase.tearDown(JdbcTestCase.java:79)
    at 
org.springframework.jdbc.object.SqlQueryTestSuite.tearDown(SqlQueryTestSuite.java:54)

Re: [Springframework-developer] Revised BeanFactoryLocator and EJB support classes

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

Juergen,

In fact w/regards to your refactoring of the BeanFactoryLocator and 
related classes, you had only taken out the inner class 
BeanFactoryReference from the JndiBeanFactoryLocator variants (and added 
close() calls on the release()), and there was no problem with that, 
since those classes never used a reference count. You actually left 
alone the no-op inner class variants in 
SingletonBeanFactoryLocator/ContextSingletonBeanFactoryLoctor which did 
nothing on the release() call.

But since it needed to be done anyways though, I have gone ahead and 
finished the code in those classes to actually decide whether to call 
close() or not, on release(), based on the reference count that is kept..

Regards,
Colin


jürgen höller [werk3AT] wrote:

>Colin,
> 
>Oops, I seem to have gotten that wrong then for the SingletonBeanFactoryLocator: Please change it back to a more reasonable implementation before 1.0 final. 
> 
>However, the JndiBeanFactoryLocator doesn't have a reference count; it creates the factory on each locator call. Isn't it be appropriate here to call BeanFactory.destroySingletons respectively ApplicationContext.close on release?
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: Sa 14.02.2004 20:06
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Revised BeanFactoryLocator and EJB support classes
>
>
>
>I've got no problem with these changes in terms of making the names
>consistent. The new handling of the BeanFactoryReference is wrong
>though. There was a reason why it was an inner class before, as per the
>comment:
>
>            return new BeanFactoryReference() {
>                public BeanFactory getFactory() {
>                    return retval;
>                }
>                public void release() throws FatalBeanException {
>                    // Currently does nothing.
>                    // An ideal implementation would use reference
>counting data to release owning
>                    // container when no more BeanFactories within it
>are used, however depending on
>                    // the usage scenario, this could also cause thrashing.
>                }
>            };
>
>Now it was somewhat of a copout not to do anything on the release; my
>original intent when I checked this stuff in was that we would have some
>discussion on the best handling for the release call, and then it would
>get implemented, probably to just use the reference count in its outer
>class to decide whether to release or not, but we've all been pretty
>busy and that didn't happen.
>
>So you can not just call
>   ((ConfigurableBeanFactory) this.beanFactory).destroySingletons()
>and
>   ((ConfigurableApplicationContext) this.applicationContext).close();
>as your new implementation does in the new separate implementations of
>BeanFactoryReference. It should probably stay an inner class, and only
>call the destroy or close, respectively, if the reference count on the
>keyed singleton beanfactory or context goes down to zero.
>:
>This will work absolutely fine for people using it like I am, where it
>is used to obtain the parent for the web application context(s), and
>then only released when the web application context gets unloaded.
>
>The other situation, where people do not have one get and release
>wrapping all other gets and releases, is more problematic, since if they
>do sequential gets and releases they will get a sort of thrashing as
>stuff gets continuously loaded and unloaded. What these people will have
>to do is themselves force an initial load without a release, at their
>app startup.
>
>As for the default ejbRemove not calling unloadBeanFactory (like the
>comment for unloadBeanFActory says is supposed to happen), that appears
>to be an oversight and something that was in there since Nov. or Dec.
>Thanks for catching that. The old old code never did any unloading at
>all. Then in Nov./Dec. I added the unloadBeanFactory method, but
>apparently forgot to call it.
>
>Regards,
>Colin
>
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Agreed, the RC1 API should be considered as final as possible. However, the BeanFactoryLocator was a brand-new RC1 feature, added pretty much last minute there, so I guess it's arguable to refine this for 1.0 final - particularly if it just affects advanced users that diverge from the default EJB support configuration.
>>
>>    
>>
>>From my point of view, I'm as happy as can be with the current state of the framework. What I would like to see included in 1.0 final nevertheless is (backward-compatible) support for more exception categories in the SQLException translator, as suggested by Thomas, and possibly a convenient option to set a transaction rollback-only no matter if driven by declarative or programmatic demarcation, as suggested by Colin and Alef.
>  
>
>>BTW, I'll send a mail regarding the Spring roadmap shortly.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von Rod Johnson
>>Gesendet: Sa 14.02.2004 18:42
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] Revised BeanFactoryLocator and EJB support classes
>>
>>
>>
>>I agree with these changes, but I think we should try to avoid API changes
>>in general from now to 1.0 final. With RC1 we are committing to a final API.
>>Also, I'd rather we don't have enough changes that we need an RC2.
>>
>>Regards,
>>Rod
>>
>>----- Original Message -----
>>From: "jürgen höller [werk3AT]" <jue...@we...>
>>To: <spr...@li...>
>>Sent: Saturday, February 14, 2004 5:22 PM
>>Subject: [Springframework-developer] Revised BeanFactoryLocator and EJB
>>support classes
>>
>>
>>Colin, Rod, everyone,
>>
>>I revised the BeanFactoryLocator and EJB support classes yesterday, mainly
>>to align the naming of the implementation classes with Spring's general
>>naming patterns. For example, the ApplicationContext-specific classes are
>>now called "ContextJndiBeanFactoryLocator" and
>>"ContextSingletonBeanFactoryLocator". I've also factored out the
>>BeanFactoryReference implementations for newly created BeanFactories into
>>separate classes, making them invoke
>>"ConfigurableBeanFactory.destroySingletons" respectively
>>"ConfigurableApplicationContext.close" on release.
>>
>>I've adapted the EJB support classes accordingly and, on the occasion, moved
>>the logger instance variable from AbstractEnterpriseBean to
>>AbstractStatelessSessionBean and AbstractMessageDriverBean. Someone
>>complained on the mailing list a while ago that removing and setting the
>>logger instance for SFSBs is a nuisance, and I agree - the subclass should
>>hold its own *static* logger instance there. Of course, this doesn't apply
>>to SLSBs and MDBs, thus the change.
>>
>>I've also noted that AbstractEnterpriseBean's "ejbRemove" implementation did
>>*not* invoke BeanFactoryLocator.release; is there any rationale for this?
>>For the time being, I've made it invoke release, as I consider it important
>>to destroy resource singletons like a local SessionFactory or
>>PersistenceManager on BeanFactory respectively ApplicationContext shutdown.
>>
>>I hope you don't mind the name changes. My goal is to keep class and method
>>naming as consistent as possible within the Spring codebase; something many
>>other open source projects to not respect at all.
>>
>>Juergen
>>
>>    
>>

Re: [Springframework-developer] branching CVS

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

You can indeed branch off a tag. The reason why you would want to go 
ahead and actually create the branch is that you actually want to commit 
code to both the branch and HEAD.

For 3-4 weeks, I personally have no time to do even as much 1.0 stuff as 
I'd like to, never mind 1.1 features, so a branch makes sense only if 
other people want to check in code there.


jürgen höller [werk3AT] wrote:

>I may be totally off the track here, but can't we simply branch from the "release-1-0" tag in CVS then - on demand? IIRC, CVS allows to branch from any tag in the past, doesn't it?
> 
>The only disadvantage is that 1.1 work should not be committed to CVS head before the 1.0 final snapshot gets taken. However, this does not seem to be a problem for me, as 1.0 final will be released soon enough.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Rod Johnson
>Gesendet: Di 17.02.2004 22:29
>An: spr...@li...
>Betreff: Re: [Springframework-developer] branching CVS
>
>
>
>Yes, I think we're going to have to do this soon. I was against it earlier
>as we were still adding new features.
>
>----- Original Message -----
>From: "Darren Davison" <da...@da...>
>To: <spr...@li...>
>Sent: Tuesday, February 17, 2004 8:47 PM
>Subject: [Springframework-developer] branching CVS
>
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I remember this being asked a while back, but are there any plans to branch
>the 1.0 code in CVS so that HEAD continues to be used for 1.1 and beyond?
>If not, how will 1.0 bugs/revisions be handled once new features begin to
>be implemented?
>
>- --
>
>Darren Davison
>Public Key: http://www.davison.uk.net/key.jsp
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.3 (GNU/Linux)
>
>iD8DBQFAMn3YKLMLAN01aw0RAg1+AJ9SwnsV4Mpyf8IPn6WBu4K6PcPiEQCbBkGQ
>JFXwaxVq/0EnIRpb6iMsIzQ=
>=VgU+
>-----END PGP SIGNATURE-----
>  
>

Re: [Springframework-developer] JdbcHelper

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

Agreed. I can kill some convenience methods that do essentially the same 
thing...

jürgen höller [werk3AT] wrote:

>Great! This is really a convenient way to execute simple SQL statements, both for update and for query. 
> 
>Allowing for using PreparedStatements without having to implement a PreparedStatementSetter is a significant benefit, as is giving easy access to simple results, avoiding the need for implementing a RowCallbackHandler. int results are worth special support here, as aggregate functions (count etc) all have integer results.
> 
>I guess this is as good as it gets in a programmatic fashion. For declarative statements declarations and declarative parameter and/or result mappings, iBATIS SQL Maps is the way to go. Both approaches have clear value; it's good to see them both tap their respective full potential.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von tri...@tr...
>Gesendet: Di 17.02.2004 20:02
>An: spr...@li...
>Betreff: RE: [Springframework-developer] JdbcHelper
>
>
>
>I like the changes - the new method names fit better with the rest of the
>JdbcTemplate and Rod got his convenience 'int' method.  Unfortunaltely it did
>not work to well for Oracle since getObject() maps a NUMERIC to
>java.math.BigDecimal.  I added an explicit new Integer(getInt()) when the target
>is an Integer and the result looks like it could be an integer (NUMERIC,
>INTEGER, SMALLINT, TINYINT).
>
>These all work for Oracle:
>int i1 = jt.queryForInt("select count(*) from emp");
>Object o2 = jt.queryForObject("select sysdate from dual", java.util.Date.class);
>Object o3 = jt.queryForObject("select to_number('12.456', '9999.999') from
>dual", Number.class);
>Object o4 = jt.queryForList("select * from emp");
>
>
>Quoting "jürgen höller [werk3AT]" <jue...@we...>:
>
>  
>
>>I've reviewed the code, and I think it's good that we're addressing this =
>>in JdbcTemplate itself. However, on second thought, it seems confusing =
>>to have a runSqlStatement method that executes either a query or update, =
>>with a multitude of possible result semantics. Thus, I've refactored =
>>this into overloaded query/queryForList/queryForObject/queryForInt =
>>methods.
>>
>>I've also added corresponding queryXxx and update methods that work with =
>>PreparedStatements, taking an Object[] (and optionally a int[] array for =
>>the SQL types) as arguments that get bound to the PreparedStatement. =
>>This effectively offers some of the conveniences of SqlQuery's find =
>>methods in JdbcTemplate itself; I think that's a valuable addition.
>>
>>Furthermore, I've put the new methods in JdbcOperations. In the course =
>>of this, I've dropped doWithResultFromXxx methods from the =
>>JdbcOperations interface: This is not something to be used on a regular =
>>basis, thus I guess it's enough to make them available in JdbcTemplate =
>>itself. This completely avoids the need to refer to the =
>>ResultSetExtractor interface in the JdbcOperations interface.
>>
>>As a further minor change, I've allowed ResultSetExtractor to return an =
>>arbitrary result object. The doWithResultFromXxx methods simply pass =
>>this through. The new queryForList/queryForObject/queryForInt methods =
>>are more elegant to implement with this. Finally, I've also moved =
>>ColumnExtractor and DefaultColumnExtractor to the sandbox: They were =
>>just used by JdbcHelper.
>>
>>(to be committed in about half an hour)
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of tri...@tr...
>>Sent: Monday, February 16, 2004 10:16 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] JdbcHelper
>>
>>
>>
>>I have committed the new method to CVS.  I will add my local tests to =
>>the proper
>>test class later today or tomorrow (this is a standalone feature so =
>>little risk
>>of breaking any other functionality).  This might actually turn out to =
>>be more
>>of a test of MockObjects than real code, but it will at least outline =
>>expected
>>functionality.
>>
>>I ended up implementing (3) as an ArrayList of HashMaps using the column =
>>name as
>>key.  We could replace this with a disconnected rowset in the future.
>>
>>I'll think about the convenience method - is "int" sufficient?
>>
>>Here is an example:
>>
>>DriverManagerDataSource ds =3D new DriverManagerDataSource();
>>ds.setDriverClassName("oracle.jdbc.driver.OracleDriver");
>>ds.setUrl("jdbc:oracle:thin:@localhost:1521:ORCL");
>>ds.setUsername("scott");
>>ds.setPassword("tiger");
>>JdbcTemplate jt =3D new JdbcTemplate(ds);
>>Object o =3D jt.runSqlStatement("select * from emp");
>>System.out.println(o.getClass().getName());
>>System.out.println(o);
>>
>>java.util.ArrayList
>>[{SAL=3D800, HIREDATE=3D1980-12-17 00:00:00.0, COMM=3Dnull, =
>>EMPNO=3D7369, JOB=3DCLERK,
>>DEPTNO=3D20, MGR=3D7902, ENAME=3DSMITH}, {SAL=3D1600, =
>>HIREDATE=3D1981-02-20 00:00:00.0,
>>COMM=3D300, EMPNO=3D7499, JOB=3DSALESMAN, DEPTNO=3D30, MGR=3D7698, =
>>ENAME=3DALLEN},
>>{SAL=3D1250, HIREDATE=3D1981-02-22 00:00:00.0, COMM=3D500, EMPNO=3D7521, =
>>JOB=3DSALESMAN,
>>DEPTNO=3D30, MGR=3D7698, ENAME=3DWARD}, {SAL=3D2975, =
>>HIREDATE=3D1981-04-02 00:00:00.0,
>>COMM=3Dnull, EMPNO=3D7566, JOB=3DMANAGER, DEPTNO=3D20, MGR=3D7839, =
>>ENAME=3DJONES},
>>{SAL=3D1250, HIREDATE=3D1981-09-28 00:00:00.0, COMM=3D1400, =
>>EMPNO=3D7654, JOB=3DSALESMAN,
>>DEPTNO=3D30, MGR=3D7698, ENAME=3DMARTIN}, {SAL=3D2850, =
>>HIREDATE=3D1981-05-01 00:00:00.0,
>>COMM=3Dnull, EMPNO=3D7698, JOB=3DMANAGER, DEPTNO=3D30, MGR=3D7839, =
>>ENAME=3DBLAKE},
>>{SAL=3D2450, HIREDATE=3D1981-06-09 00:00:00.0, COMM=3Dnull, =
>>EMPNO=3D7782, JOB=3DMANAGER,
>>DEPTNO=3D10, MGR=3D7839, ENAME=3DCLARK}, {SAL=3D3000, =
>>HIREDATE=3D1987-04-19 00:00:00.0,
>>COMM=3Dnull, EMPNO=3D7788, JOB=3DANALYST, DEPTNO=3D20, MGR=3D7566, =
>>ENAME=3DSCOTT},
>>{SAL=3D5000, HIREDATE=3D1981-11-17 00:00:00.0, COMM=3Dnull, =
>>EMPNO=3D7839, JOB=3DPRESIDENT,
>>DEPTNO=3D10, MGR=3Dnull, ENAME=3DKING}, {SAL=3D1500, =
>>HIREDATE=3D1981-09-08 00:00:00.0,
>>COMM=3D0, EMPNO=3D7844, JOB=3DSALESMAN, DEPTNO=3D30, MGR=3D7698, =
>>ENAME=3DTURNER}, {SAL=3D1100,
>>HIREDATE=3D1987-05-23 00:00:00.0, COMM=3Dnull, EMPNO=3D7876, =
>>JOB=3DCLERK, DEPTNO=3D20,
>>MGR=3D7788, ENAME=3DADAMS}, {SAL=3D950, HIREDATE=3D1981-12-03 =
>>00:00:00.0, COMM=3Dnull,
>>EMPNO=3D7900, JOB=3DCLERK, DEPTNO=3D30, MGR=3D7698, ENAME=3DJAMES}, =
>>{SAL=3D3000,
>>HIREDATE=3D1981-12-03 00:00:00.0, COMM=3Dnull, EMPNO=3D7902, =
>>JOB=3DANALYST, DEPTNO=3D20,
>>MGR=3D7566, ENAME=3DFORD}, {SAL=3D1300, HIREDATE=3D1982-01-23 =
>>00:00:00.0, COMM=3Dnull,
>>EMPNO=3D7934, JOB=3DCLERK, DEPTNO=3D10, MGR=3D7782, ENAME=3DMILLER}]
>>
>>Thomas
>>
>>
>>Quoting Rod Johnson <rod...@in...>:
>>
>>    
>>
>>>Thomas,
>>>=20
>>>Sounds great. With this there I'd be glad to get rid of JdbcHelper.
>>>=20
>>>Not sure about (3). I think this needs further thought. For 1.1 we =
>>>      
>>>
>>could add
>>    
>>
>>>a true disconnected result set: not RowSet as it throws SQLException, =
>>>      
>>>
>>which
>>    
>>
>>>we want to get away from.
>>>=20
>>>Also a convenience method returning int would be handy, for counts and =
>>>      
>>>
>>the
>>    
>>
>>>like. Please can I have this, despite Juergen's dislike of convenience
>>>methods :-)
>>>=20
>>>Regards,
>>>Rod
>>>=20
>>>----- Original Message -----
>>>From: <tri...@tr...>
>>>To: <spr...@li...>
>>>Sent: Monday, February 16, 2004 5:26 PM
>>>Subject: RE: [Springframework-developer] JdbcHelper
>>>=20
>>>=20
>>>      
>>>
>>>>I can see the need to go beyond a single row/value type query.
>>>>
>>>>How about a new method for the JdbcTemplate:
>>>>
>>>>Object runSqlStatement(String)
>>>>
>>>>Based on the type of SQL passed in it would return:
>>>>
>>>>1) An Integer containing the number of rows affected if it is an =
>>>>        
>>>>
>>update
>>    
>>
>>>statement
>>>      
>>>
>>>>runSqlStatement("update emp set salary =3D salary * 1.5") would =
>>>>        
>>>>
>>return an
>>    
>>
>>>Integer
>>>      
>>>
>>>>with the update count
>>>>
>>>>2) A single Object (Integer/Long/String) based on the value returned =
>>>>        
>>>>
>>from
>>    
>>
>>>a
>>>      
>>>
>>>>single value/single row query
>>>>
>>>>runSqlStatement("select last_name frmo emp where id =3D 2") would =
>>>>        
>>>>
>>return a
>>    
>>
>>>String
>>>      
>>>
>>>>containing the last name
>>>>
>>>>3) An ArrayList of ArrayLists containing a list of rows with a list =
>>>>        
>>>>
>>of
>>    
>>
>>>column
>>>      
>>>
>>>>values returned by the query
>>>>
>>>>runSqlStatement("selecy id, last_name from emp") would return an =
>>>>        
>>>>
>>ArrayList
>>    
>>
>>>>containing an ArrayList for each row.  The second list would contain =
>>>>        
>>>>
>>an
>>    
>>
>>>Integer
>>>      
>>>
>>>>with the id and a String with the last_name.
>>>>
>>>>
>>>>Number 3 might be a stretch, but we would still have to check for =
>>>>        
>>>>
>>this,
>>    
>>
>>>since we
>>>      
>>>
>>>>have no control over the SQL coming in.
>>>>
>>>>Thomas
>>>>
>>>>
>>>>Quoting rod...@in...:
>>>>
>>>>        
>>>>
>>>>>I've actually just (yesterday) introduced into into a whole
>>>>>bunch of test cases at a client. Maybe we could put an
>>>>>improved runSQLFunction() method on JdbcTemplate? This is a
>>>>>very convenient one-liner, and basically the only reason I
>>>>>use JdbcTemplate.
>>>>>
>>>>>Regards,
>>>>>Rod
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>>>>>Build and deploy apps & Web services for Linux with
>>>>>a free DVD software kit from IBM. Click Now!
>>>>>http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
>>>>>_______________________________________________
>>>>>Springframework-developer mailing list
>>>>>Spr...@li...
>>>>>=
>>>>>          
>>>>>
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>    
>>
>>>>        
>>>>

Re: [Springframework-developer] Re: [springframework - Open Discussion] Two feature requests

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

It doesn't feel incredibly clean to me, but I am not opposed to adding 
it. My one concern would be if this constrained us somehow for future 
enhancements, but I can't think of any issues right now...


jürgen höller [werk3AT] wrote:

>I'd like to hear further opinions on this... Does anyone strongly object to adding that shortcut style as option? Anyone actually preferring the shortcut style? I wouldn't use it myself, but I don't mind the option.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Rod Johnson
>Gesendet: Di 17.02.2004 22:50
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Re: [springframework - Open Discussion] Two feature requests
>
>
>
>Well if it's backward compatible... But I don't think we should advocate
>this.
>
>----- Original Message -----
>From: "jürgen höller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Tuesday, February 17, 2004 7:10 PM
>Subject: [Springframework-developer] Re: [springframework - Open Discussion]
>Two feature requests
>
>
>Actually, this is extremely easy to implement: I've just adapted
>DefaultXmlBeanDefinitionParser and it works nicely, still allowing for
><value> tags but also for text values as CDATA...
>
>Of course, I do appreciate the explicit notion of a value, but I guess we
>should allow for this shortcut style too - we shouldn't force people into a
>certain style here.
>
>If noone objects, I'll commit this promptly.
>
>Juergen
>
>
>________________________________
>
>Von: jürgen höller [werk3AT]
>Gesendet: Di 17.02.2004 20:02
>An: spr...@li...
>Betreff: Fw: [springframework - Open Discussion] Two feature requests
>
>
>Any thoughts on suggestion number 2? As I wrote in that forum, I've
>considered that myself repeatedly...
>
>Juergen
>
>
>________________________________
>
>Von: SourceForge.net [mailto:no...@so...]
>Gesendet: Mo 16.02.2004 18:10
>An: no...@so...
>Betreff: [springframework - Open Discussion] Two feature requests
>
>
>
>
>Read and respond to this message at:
>https://sourceforge.net/forum/message.php?msg_id=2425898
>By: aaron
>
>Since there are no trackers...
>
>I have two feature requests, and some comments
>
>1) Add a default attribute to the ParameterMethodNameResolver.  Currently,
>if
>the parameter is not present, this resolver just bombs all over... Having a
>default would be trivial to implement and allow the developer to let the
>application
>proceed when a parameter was not provided (no reason to pollute the GET url)
>
>2) This might be a religious issue, but it would be very convenient if
>the requirement of using a nested <value> element in <property> elements,
>for
>values was lifted.  Either there is CDATA (in which case we assume it's a
>literal
>value), or there are nested elements.  Having both could simply result in a
>configuration error.  This would save typing and lots of cumbersome errors
>relating
>to not including the nested <value> element.  Also, some docs give examples
>with literals without this <value> element.
>
>The other things I've run into is: in mapping handlers, although you can
>inspect
>the request and response arguments, you cannot rewrite them (since the
>interfaces
>do not provide mutators).  This makes using request wrappers impossible.  I
>suggest another form of method signature for handlers which take objects
>which
>hold a reference to HttpServletRequest and HttpServletResponse respectively,
>instead of having those objects as direct, immutable arguments.
>
>To get around this I have overridden a handleRequestInternal method in my
>controller
>and just call super.handleRequestInternal giving it
>my HttpServletRequestWrapper.
>  
>

RE: [Springframework-developer] Re: [springframework - Open Discussion] Two feature requests

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

Oh, oops, my bad. My other opinion still stands tho.  :)

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Tuesday, February 17, 2004 5:54 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests


Ehm, regarding a request for it, have a look at the subject ;-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag
von Tim Kettering
Gesendet: Di 17.02.2004 23:31
An: spr...@li...
Betreff: RE: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests




I don't have an opinion either way, but if nobody's requested it -
(don't know if someone did)then why add it?  That's where feature bloat
comes from, and I don't necessarily see XML as an data-type that
encourages/promotes shortcuts.  Just ask any web designer where HTML got
us.

-tim

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Tuesday, February 17, 2004 5:11 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests


I'd like to hear further opinions on this... Does anyone strongly object
to adding that shortcut style as option? Anyone actually preferring the
shortcut style? I wouldn't use it myself, but I don't mind the option.

Juergen


________________________________

Von: spr...@li... im Auftrag
von Rod Johnson
Gesendet: Di 17.02.2004 22:50
An: spr...@li...
Betreff: Re: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests



Well if it's backward compatible... But I don't think we should advocate
this.

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Tuesday, February 17, 2004 7:10 PM
Subject: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests


Actually, this is extremely easy to implement: I've just adapted
DefaultXmlBeanDefinitionParser and it works nicely, still allowing for
<value> tags but also for text values as CDATA...

Of course, I do appreciate the explicit notion of a value, but I guess
we should allow for this shortcut style too - we shouldn't force people
into a certain style here.

If noone objects, I'll commit this promptly.

Juergen


________________________________

Von: j=FCrgen h=F6ller [werk3AT]
Gesendet: Di 17.02.2004 20:02
An: spr...@li...
Betreff: Fw: [springframework - Open Discussion] Two feature requests


Any thoughts on suggestion number 2? As I wrote in that forum, I've
considered that myself repeatedly...

Juergen


________________________________

Von: SourceForge.net [mailto:no...@so...]
Gesendet: Mo 16.02.2004 18:10
An: no...@so...
Betreff: [springframework - Open Discussion] Two feature requests




Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=3D2425898
By: aaron

Since there are no trackers...

I have two feature requests, and some comments

1) Add a default attribute to the ParameterMethodNameResolver.
Currently, if the parameter is not present, this resolver just bombs all
over... Having a default would be trivial to implement and allow the
developer to let the application proceed when a parameter was not
provided (no reason to pollute the GET url)

2) This might be a religious issue, but it would be very convenient if
the requirement of using a nested <value> element in <property>
elements, for values was lifted.  Either there is CDATA (in which case
we assume it's a literal value), or there are nested elements.  Having
both could simply result in a configuration error.  This would save
typing and lots of cumbersome errors relating to not including the
nested <value> element.  Also, some docs give examples with literals
without this <value> element.

The other things I've run into is: in mapping handlers, although you can
inspect the request and response arguments, you cannot rewrite them
(since the interfaces do not provide mutators).  This makes using
request wrappers impossible.  I suggest another form of method signature
for handlers which take objects which hold a reference to
HttpServletRequest and HttpServletResponse respectively, instead of
having those objects as direct, immutable arguments.

To get around this I have overridden a handleRequestInternal method in
my controller and just call super.handleRequestInternal giving it my
HttpServletRequestWrapper.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=3D250339




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: [springframework - Open Discussion] Two feature requests

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

Ehm, regarding a request for it, have a look at the subject ;-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Tim Kettering
Gesendet: Di 17.02.2004 23:31
An: spr...@li...
Betreff: RE: [Springframework-developer] Re: [springframework - Open =
Discussion] Two feature requests




I don't have an opinion either way, but if nobody's requested it -
(don't know if someone did)then why add it?  That's where feature bloat
comes from, and I don't necessarily see XML as an data-type that
encourages/promotes shortcuts.  Just ask any web designer where HTML got
us.

-tim

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Tuesday, February 17, 2004 5:11 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests


I'd like to hear further opinions on this... Does anyone strongly object
to adding that shortcut style as option? Anyone actually preferring the
shortcut style? I wouldn't use it myself, but I don't mind the option.

Juergen


________________________________

Von: spr...@li... im Auftrag
von Rod Johnson
Gesendet: Di 17.02.2004 22:50
An: spr...@li...
Betreff: Re: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests



Well if it's backward compatible... But I don't think we should advocate
this.

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Tuesday, February 17, 2004 7:10 PM
Subject: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests


Actually, this is extremely easy to implement: I've just adapted
DefaultXmlBeanDefinitionParser and it works nicely, still allowing for
<value> tags but also for text values as CDATA...

Of course, I do appreciate the explicit notion of a value, but I guess
we should allow for this shortcut style too - we shouldn't force people
into a certain style here.

If noone objects, I'll commit this promptly.

Juergen


________________________________

Von: j=FCrgen h=F6ller [werk3AT]
Gesendet: Di 17.02.2004 20:02
An: spr...@li...
Betreff: Fw: [springframework - Open Discussion] Two feature requests


Any thoughts on suggestion number 2? As I wrote in that forum, I've
considered that myself repeatedly...

Juergen


________________________________

Von: SourceForge.net [mailto:no...@so...]
Gesendet: Mo 16.02.2004 18:10
An: no...@so...
Betreff: [springframework - Open Discussion] Two feature requests




Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=3D2425898
By: aaron

Since there are no trackers...

I have two feature requests, and some comments

1) Add a default attribute to the ParameterMethodNameResolver.
Currently, if the parameter is not present, this resolver just bombs all
over... Having a default would be trivial to implement and allow the
developer to let the application proceed when a parameter was not
provided (no reason to pollute the GET url)

2) This might be a religious issue, but it would be very convenient if
the requirement of using a nested <value> element in <property>
elements, for values was lifted.  Either there is CDATA (in which case
we assume it's a literal value), or there are nested elements.  Having
both could simply result in a configuration error.  This would save
typing and lots of cumbersome errors relating to not including the
nested <value> element.  Also, some docs give examples with literals
without this <value> element.

The other things I've run into is: in mapping handlers, although you can
inspect the request and response arguments, you cannot rewrite them
(since the interfaces do not provide mutators).  This makes using
request wrappers impossible.  I suggest another form of method signature
for handlers which take objects which hold a reference to
HttpServletRequest and HttpServletResponse respectively, instead of
having those objects as direct, immutable arguments.

To get around this I have overridden a handleRequestInternal method in
my controller and just call super.handleRequestInternal giving it my
HttpServletRequestWrapper.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=3D250339




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Re: [springframework - Open Discussion] Two feature requests

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

I don=92t have an opinion either way, but if nobody's requested it -
(don=92t know if someone did)then why add it?  That=92s where feature =
bloat
comes from, and I don=92t necessarily see XML as an data-type that
encourages/promotes shortcuts.  Just ask any web designer where HTML got
us.

-tim

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Tuesday, February 17, 2004 5:11 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests


I'd like to hear further opinions on this... Does anyone strongly object
to adding that shortcut style as option? Anyone actually preferring the
shortcut style? I wouldn't use it myself, but I don't mind the option.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag
von Rod Johnson
Gesendet: Di 17.02.2004 22:50
An: spr...@li...
Betreff: Re: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests



Well if it's backward compatible... But I don't think we should advocate
this.

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Tuesday, February 17, 2004 7:10 PM
Subject: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests


Actually, this is extremely easy to implement: I've just adapted
DefaultXmlBeanDefinitionParser and it works nicely, still allowing for
<value> tags but also for text values as CDATA...

Of course, I do appreciate the explicit notion of a value, but I guess
we should allow for this shortcut style too - we shouldn't force people
into a certain style here.

If noone objects, I'll commit this promptly.

Juergen


________________________________

Von: j=FCrgen h=F6ller [werk3AT]
Gesendet: Di 17.02.2004 20:02
An: spr...@li...
Betreff: Fw: [springframework - Open Discussion] Two feature requests


Any thoughts on suggestion number 2? As I wrote in that forum, I've
considered that myself repeatedly...

Juergen


________________________________

Von: SourceForge.net [mailto:no...@so...]
Gesendet: Mo 16.02.2004 18:10
An: no...@so...
Betreff: [springframework - Open Discussion] Two feature requests




Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=3D2425898
By: aaron

Since there are no trackers...

I have two feature requests, and some comments

1) Add a default attribute to the ParameterMethodNameResolver.
Currently, if the parameter is not present, this resolver just bombs all
over... Having a default would be trivial to implement and allow the
developer to let the application proceed when a parameter was not
provided (no reason to pollute the GET url)

2) This might be a religious issue, but it would be very convenient if
the requirement of using a nested <value> element in <property>
elements, for values was lifted.  Either there is CDATA (in which case
we assume it's a literal value), or there are nested elements.  Having
both could simply result in a configuration error.  This would save
typing and lots of cumbersome errors relating to not including the
nested <value> element.  Also, some docs give examples with literals
without this <value> element.

The other things I've run into is: in mapping handlers, although you can
inspect the request and response arguments, you cannot rewrite them
(since the interfaces do not provide mutators).  This makes using
request wrappers impossible.  I suggest another form of method signature
for handlers which take objects which hold a reference to
HttpServletRequest and HttpServletResponse respectively, instead of
having those objects as direct, immutable arguments.

To get around this I have overridden a handleRequestInternal method in
my controller and just call super.handleRequestInternal giving it my
HttpServletRequestWrapper.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=3D250339




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: [springframework - Open Discussion] Two feature requests

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

I'd like to hear further opinions on this... Does anyone strongly object =
to adding that shortcut style as option? Anyone actually preferring the =
shortcut style? I wouldn't use it myself, but I don't mind the option.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: Di 17.02.2004 22:50
An: spr...@li...
Betreff: Re: [Springframework-developer] Re: [springframework - Open =
Discussion] Two feature requests



Well if it's backward compatible... But I don't think we should advocate
this.

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Tuesday, February 17, 2004 7:10 PM
Subject: [Springframework-developer] Re: [springframework - Open =
Discussion]
Two feature requests


Actually, this is extremely easy to implement: I've just adapted
DefaultXmlBeanDefinitionParser and it works nicely, still allowing for
<value> tags but also for text values as CDATA...

Of course, I do appreciate the explicit notion of a value, but I guess =
we
should allow for this shortcut style too - we shouldn't force people =
into a
certain style here.

If noone objects, I'll commit this promptly.

Juergen


________________________________

Von: j=FCrgen h=F6ller [werk3AT]
Gesendet: Di 17.02.2004 20:02
An: spr...@li...
Betreff: Fw: [springframework - Open Discussion] Two feature requests


Any thoughts on suggestion number 2? As I wrote in that forum, I've
considered that myself repeatedly...

Juergen


________________________________

Von: SourceForge.net [mailto:no...@so...]
Gesendet: Mo 16.02.2004 18:10
An: no...@so...
Betreff: [springframework - Open Discussion] Two feature requests




Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=3D2425898
By: aaron

Since there are no trackers...

I have two feature requests, and some comments

1) Add a default attribute to the ParameterMethodNameResolver.  =
Currently,
if
the parameter is not present, this resolver just bombs all over... =
Having a
default would be trivial to implement and allow the developer to let the
application
proceed when a parameter was not provided (no reason to pollute the GET =
url)

2) This might be a religious issue, but it would be very convenient if
the requirement of using a nested <value> element in <property> =
elements,
for
values was lifted.  Either there is CDATA (in which case we assume it's =
a
literal
value), or there are nested elements.  Having both could simply result =
in a
configuration error.  This would save typing and lots of cumbersome =
errors
relating
to not including the nested <value> element.  Also, some docs give =
examples
with literals without this <value> element.

The other things I've run into is: in mapping handlers, although you can
inspect
the request and response arguments, you cannot rewrite them (since the
interfaces
do not provide mutators).  This makes using request wrappers impossible. =
 I
suggest another form of method signature for handlers which take objects
which
hold a reference to HttpServletRequest and HttpServletResponse =
respectively,
instead of having those objects as direct, immutable arguments.

To get around this I have overridden a handleRequestInternal method in =
my
controller
and just call super.handleRequestInternal giving it
my HttpServletRequestWrapper.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=3D250339




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] branching CVS

[Rod J. <rod...@in...>]

Yes, I agree.

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Tuesday, February 17, 2004 9:35 PM
Subject: Re: [Springframework-developer] branching CVS


I may be totally off the track here, but can't we simply branch from the
"release-1-0" tag in CVS then - on demand? IIRC, CVS allows to branch fro=
m
any tag in the past, doesn't it?

The only disadvantage is that 1.1 work should not be committed to CVS hea=
d
before the 1.0 final snapshot gets taken. However, this does not seem to =
be
a problem for me, as 1.0 final will be released soon enough.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Rod Johnson
Gesendet: Di 17.02.2004 22:29
An: spr...@li...
Betreff: Re: [Springframework-developer] branching CVS



Yes, I think we're going to have to do this soon. I was against it earlie=
r
as we were still adding new features.

----- Original Message -----
From: "Darren Davison" <da...@da...>
To: <spr...@li...>
Sent: Tuesday, February 17, 2004 8:47 PM
Subject: [Springframework-developer] branching CVS


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I remember this being asked a while back, but are there any plans to bran=
ch
the 1.0 code in CVS so that HEAD continues to be used for 1.1 and beyond?
If not, how will 1.0 bugs/revisions be handled once new features begin to
be implemented?

- --

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAMn3YKLMLAN01aw0RAg1+AJ9SwnsV4Mpyf8IPn6WBu4K6PcPiEQCbBkGQ
JFXwaxVq/0EnIRpb6iMsIzQ=3D
=3DVgU+
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: [springframework - Open Discussion] Two feature requests

[Rod J. <rod...@in...>]

Well if it's backward compatible... But I don't think we should advocate
this.

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Tuesday, February 17, 2004 7:10 PM
Subject: [Springframework-developer] Re: [springframework - Open Discussi=
on]
Two feature requests


Actually, this is extremely easy to implement: I've just adapted
DefaultXmlBeanDefinitionParser and it works nicely, still allowing for
<value> tags but also for text values as CDATA...

Of course, I do appreciate the explicit notion of a value, but I guess we
should allow for this shortcut style too - we shouldn't force people into=
 a
certain style here.

If noone objects, I'll commit this promptly.

Juergen


________________________________

Von: j=FCrgen h=F6ller [werk3AT]
Gesendet: Di 17.02.2004 20:02
An: spr...@li...
Betreff: Fw: [springframework - Open Discussion] Two feature requests


Any thoughts on suggestion number 2? As I wrote in that forum, I've
considered that myself repeatedly...

Juergen


________________________________

Von: SourceForge.net [mailto:no...@so...]
Gesendet: Mo 16.02.2004 18:10
An: no...@so...
Betreff: [springframework - Open Discussion] Two feature requests




Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=3D2425898
By: aaron

Since there are no trackers...

I have two feature requests, and some comments

1) Add a default attribute to the ParameterMethodNameResolver.  Currently=
,
if
the parameter is not present, this resolver just bombs all over... Having=
 a
default would be trivial to implement and allow the developer to let the
application
proceed when a parameter was not provided (no reason to pollute the GET u=
rl)

2) This might be a religious issue, but it would be very convenient if
the requirement of using a nested <value> element in <property> elements,
for
values was lifted.  Either there is CDATA (in which case we assume it's a
literal
value), or there are nested elements.  Having both could simply result in=
 a
configuration error.  This would save typing and lots of cumbersome error=
s
relating
to not including the nested <value> element.  Also, some docs give exampl=
es
with literals without this <value> element.

The other things I've run into is: in mapping handlers, although you can
inspect
the request and response arguments, you cannot rewrite them (since the
interfaces
do not provide mutators).  This makes using request wrappers impossible. =
 I
suggest another form of method signature for handlers which take objects
which
hold a reference to HttpServletRequest and HttpServletResponse respective=
ly,
instead of having those objects as direct, immutable arguments.

To get around this I have overridden a handleRequestInternal method in my
controller
and just call super.handleRequestInternal giving it
my HttpServletRequestWrapper.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=3D250339




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Fw: [springframework - Open Discussion] Two feature requests

[Rod J. <rod...@in...>]

I'm not keen to relax this. I think XML structures where you get "either =
an
element or text" are messy.

I'm not "religious" on it, but I like the present approach. With XMLBuddy=
 or
any decent XML editor it's a non-issue as it helps with the structure, an=
d
it's good to see it explicit.

Editing XML without such a tool just doesn't make sense, IMO. I haven't
typed a <value> element for months.

Regards,
Rod

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Tuesday, February 17, 2004 7:02 PM
Subject: [Springframework-developer] Fw: [springframework - Open Discussi=
on]
Two feature requests


Any thoughts on suggestion number 2? As I wrote in that forum, I've
considered that myself repeatedly...

Juergen


________________________________

Von: SourceForge.net [mailto:no...@so...]
Gesendet: Mo 16.02.2004 18:10
An: no...@so...
Betreff: [springframework - Open Discussion] Two feature requests




Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=3D2425898
By: aaron

Since there are no trackers...

I have two feature requests, and some comments

1) Add a default attribute to the ParameterMethodNameResolver.  Currently=
,
if
the parameter is not present, this resolver just bombs all over... Having=
 a
default would be trivial to implement and allow the developer to let the
application
proceed when a parameter was not provided (no reason to pollute the GET u=
rl)

2) This might be a religious issue, but it would be very convenient if
the requirement of using a nested <value> element in <property> elements,
for
values was lifted.  Either there is CDATA (in which case we assume it's a
literal
value), or there are nested elements.  Having both could simply result in=
 a
configuration error.  This would save typing and lots of cumbersome error=
s
relating
to not including the nested <value> element.  Also, some docs give exampl=
es
with literals without this <value> element.

The other things I've run into is: in mapping handlers, although you can
inspect
the request and response arguments, you cannot rewrite them (since the
interfaces
do not provide mutators).  This makes using request wrappers impossible. =
 I
suggest another form of method signature for handlers which take objects
which
hold a reference to HttpServletRequest and HttpServletResponse respective=
ly,
instead of having those objects as direct, immutable arguments.

To get around this I have overridden a handleRequestInternal method in my
controller
and just call super.handleRequestInternal giving it
my HttpServletRequestWrapper.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=3D250339




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Form View and Results View on same page issue.

[<wi...@ly...>]

I didn't totally follow your comment.  In the onSubmit(), the Controller 
would search and put in the model the search results whether returning 
to the same page or a different result page.  If it returning to the 
same view, the successView will map to the entry url mapping of the page 
and ultimately a forward request.   The referenceData would be called on 
the inbound to the page as it did on the initial request and would 
decorate the request accordingly.  So the model is only decorated if it 
returning to the same page and the controller still doesn't have to know 
that it is returning to the same view.  In essence, it is chaining the 
controllers to decorate the model.

formView = searchForm
successView = /searchForm.htm

Bill Lyvers

Trevor Cook wrote:

>>>I believe that the controller shouldn't have to be altered just because
>>>      
>>>
>it's returning to the same view
>While this sounds good, the problem is there are 2 pieces, the model and
>view.  You can use the same view by simply setting successView the same as
>formView.  The issue is that other methods (like referenceData) are not
>generating the model correctly.  While this is wrong in the scenario you
>describe, generating the model for successView all the time would mean a
>bloated model for the current usage where you are sending to a different
>view.
>
>Another simple way to handle this is to use "return showForm(...)" in the
>onSubmit method.  I personally don't like this, mainly because you still
>have extra baggage in the SimpleFormController that you aren't using.
>
>I'll post my controller this afternoon.
>
>Trevor
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of William Lyvers
>Sent: February 17, 2004 8:40 AM
>To: spr...@li...
>Subject: RE: [Springframework-developer] Form View and Results View on
>same page issue.
>
>
>First, you described the problem correctly.  The link you sent is the exact
>scenario that I was describing.  When I first realized that
>SimpleFormController wasn't going to support this type of page out of the
>box, I looked at extended BaseCommandController as you have done.  I
>resisted this mainly for 2 reasons.
>1. As you mentioned, it was yet another FormController and I didn't thing it
>was likely that it would be pulled back into Spring since there are already
>about 5 flavors of controllers.  Arguably, there may already be too many
>versions of controllers within the Framework.
>2. Personally, I believe that the controller shouldn't have to be altered
>just because it's returning to the same view.  I should be able to return a
>success view string and not have to alter my subclass just because I am
>reposting back to the same form.
>
>In either case, this is such a common scenario I would hope that the Spring
>Framework would support this out of the box by either another
>CommandController as you have suggested or enhancing SimpleFormController as
>I did in the first part of this thread.
>
>Thanks,
>Bill Lyvers
>
>I would be very interested in seeing your SelfPostingFormController.  It is
>probably a much simpler workflow since you know you are only working with
>one view.
>
>
>---------- Original Message ----------------------------------
>From: "Trevor Cook" <tc...@in...>
>Reply-To: spr...@li...
>Date:  Mon, 16 Feb 2004 22:18:54 -0500
>
>  
>
>>It sounds like your problem is with the workflow of SimpleFormController.
>>Before recommending an option, let me clarify what you are trying to do.
>>    
>>
>It
>  
>
>>sounds like it should be:
>>
>>- use posted bean to determine search params (if it exists - for "get" use
>>default values of search-param bean)
>>- return view with search results
>>
>>You don't need a "FormView"/"SuccessView", just a single view.  You also
>>would need any "referenceData" like method to be called before returning
>>    
>>
>the
>  
>
>>view, regardless of get/post.  Is this a correct understanding of your
>>problem?  If so, take a quick look at something I've implemented at
>>http://www.fotosource.com/my_local_store.html .  Basically, the filters
>>above the search results are constantly redisplayed with changing results
>>underneath.  The form also works for an initial get request (with no search
>>filters) and then successive posts (through the filter button).
>>
>>I implemented this by extending BaseCommandController
>>(SimpleFormController's "grandfather").  You can probably simply implement
>>what you're looking for by extending this class (or if necessary, step back
>>another level to AbstractController).  I never contributed this class (I
>>called it "SelfPostingFormController") because it was fairly simple to
>>implement, and considering most custom apps functionality is "exactly like
>>class X except for Y" I didn't want to bloat Spring.  Would this type of
>>class be generally useful (or has another developer already snuck this in)?
>>If multiple users want this I'll add it, otherwise I'll just post the code
>>seperately for you to use.
>>
>>Trevor
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of wi...@ly...
>>Sent: February 16, 2004 7:18 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Form View and Results View on
>>same page issue.
>>
>>
>>I posted this late last week but didn't get any bites -- maybe I'll try
>>a different angle :).
>>In short, I believe that the SimpleFormController should be enhanced to
>>support posting results back to the originating form page.  The current
>>implementation requires implementing classes to know they are returning
>>back to the originating form page.  This limits the generic ability of
>>wiring up views via IOC and getSuccessView() on SimpleFormHandler.
>>Since this is such a common scenario, I was hoping this could be
>>addressed prior to the 1.0 release.  Thoughts?
>>
>>Bill Lyvers
>>
>>
>>wi...@ly... wrote:
>>
>>    
>>
>>>I recently started using the web framework portion of Spring.  One
>>>concept in particular has bitten me a couple of times and I have been
>>>unable to determine a best practice.  The concept is how
>>>SimpleFormHandler has a different workflow based on whether it is a
>>>get request versus a post request.  This concept seemed very intuitive
>>>and works fine if the post goes off to a result page.  However, below
>>>is a scenario that I believe is quite common and SimpleFormHandler
>>>doesn't seem to deal with it very elegantly.  The problem arises when
>>>a page displays both a form and the results of a form post on the same
>>>page.
>>>
>>>Scenario:
>>>There is item search page with a item search form on the top and a
>>>tabular view of the item search results below the search page.
>>>
>>>Example Controller:
>>>public class ItemSearchController extends SimpleFormController {
>>>   private ItemManager manager;
>>>   public void setSearchManager(ItemManager manager) {
>>>       this.manager = manager;
>>>   }
>>>   protected Map referenceData(HttpServletRequest request) throws
>>>Exception {
>>>       Map map = new HashMap();
>>>       map.put( "itemTypes", manager.getItemTypes() );
>>>       return map;
>>>   }
>>>   protected ModelAndView onSubmit(Object object) throws Exception {
>>>       Item command = (Item)object;
>>>       return new ModelAndView( getSuccessView(), "items",
>>>manager.findItemsByExample( command ));
>>>   }
>>>}
>>>
>>>So, I request the page via /searchItem.htm which maps
>>>ItemSearchController.  The "get" workflow works as usual --
>>>referenceData gets called and the page displays fine.  The user
>>>submits a search criteria which then goes through "post" workflow and
>>>onSubmit gets called which returns a list of items via ModelAndView.
>>>The successView now needs to return to the same page and this time the
>>>results will be displayed below the form. However,
>>>   1. If I forward back to /searchItem.htm, then I end up in an
>>>infinite loop because the controller keeps processing it as a post.
>>>   2. If I forward on to the jsp that displayed the form originally, I
>>>will not go through the same workflow as when the page was first
>>>loaded and referenceData won't get called. Not too mention that I'll
>>>get an binding errors missing exception -- I saw that RC1 tried to
>>>address this, but only if you don't override onsubmit.
>>>
>>>So, I decided to solve the problem with option 1 and cause the form to
>>>realize that the post had already been handled and it must be a "get"
>>>request being caused by a forward.  The main reason for this is that
>>>the get workflow gets used when entering the page each.  To fix it, I
>>>overrode isFormSubmission and set an attribute when a formSubmission
>>>was recognized.  If this attribute already exists, it assumes that it
>>>is a get request instead. Example:
>>>protected boolean isFormSubmission(HttpServletRequest
>>>httpServletRequest) {
>>>       Object alreadySubmitted = httpServletRequest.getAttribute(
>>>"formSubmission");
>>>       if (alreadySubmitted != null) {
>>>           return false;
>>>       }
>>>       boolean formSubmission =
>>>super.isFormSubmission(httpServletRequest);
>>>       if( formSubmission ) {
>>>           httpServletRequest.setAttribute( "formSubmission",
>>>Boolean.TRUE );
>>>       }
>>>       return formSubmission;
>>>}
>>>
>>>
>>>I am a surprised that SimpleFormController doesn't deal with this
>>>scenario since it is so common or maybe I am missing something and it
>>>does.   With the above code you can switch out the success view to go
>>>to a seperate result page later by just changing the IOC
>>>configuration.   Basically, your controller doesn't really need to
>>>know that the results page is the same view as the form view.
>>>
>>>I am very curious on how others are dealing with this scenario and if
>>>Spring deals with it and I have just overlooked it.
>>>
>>>Keep up the good work,
>>>Bill Lyvers
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>>>Build and deploy apps & Web services for Linux with
>>>a free DVD software kit from IBM. Click Now!
>>>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>>>_______________________________________________
>>>Springframework-developer mailing list
>>>Spr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>>      
>>>
>>
>>
>>-------------------------------------------------------
>>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>>Build and deploy apps & Web services for Linux with
>>a free DVD software kit from IBM. Click Now!
>>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>-------------------------------------------------------
>>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>>Build and deploy apps & Web services for Linux with
>>a free DVD software kit from IBM. Click Now!
>>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>    
>>
>
>
>
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

Re: [Springframework-developer] branching CVS

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

I may be totally off the track here, but can't we simply branch from the =
"release-1-0" tag in CVS then - on demand? IIRC, CVS allows to branch =
from any tag in the past, doesn't it?
=20
The only disadvantage is that 1.1 work should not be committed to CVS =
head before the 1.0 final snapshot gets taken. However, this does not =
seem to be a problem for me, as 1.0 final will be released soon enough.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: Di 17.02.2004 22:29
An: spr...@li...
Betreff: Re: [Springframework-developer] branching CVS



Yes, I think we're going to have to do this soon. I was against it =
earlier
as we were still adding new features.

----- Original Message -----
From: "Darren Davison" <da...@da...>
To: <spr...@li...>
Sent: Tuesday, February 17, 2004 8:47 PM
Subject: [Springframework-developer] branching CVS


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I remember this being asked a while back, but are there any plans to =
branch
the 1.0 code in CVS so that HEAD continues to be used for 1.1 and =
beyond?
If not, how will 1.0 bugs/revisions be handled once new features begin =
to
be implemented?

- --

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAMn3YKLMLAN01aw0RAg1+AJ9SwnsV4Mpyf8IPn6WBu4K6PcPiEQCbBkGQ
JFXwaxVq/0EnIRpb6iMsIzQ=3D
=3DVgU+
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer