springframework-developer — Spring Framework developers list

[Springframework-developer] Re: HiveMind feedback/questions

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

Anybody in the Tapestry world who finds HiveMind 
(http://jakarta.apache.org/commons/sandbox/hivemind/) interesting should 
probably also take a good look at Spring Framework 
(http://www.springframework.org/). I am unfortunately much more familiar 
with Spring than with HiveMind, so it wouldn't be fair for me to try to 
qualify which containter I think is 'better' (and an assertion like this 
is usually relative to the use-case anyways), but I think anybody can 
learn a lot by looking at both approaches. While the gross functionality 
is pretty similar, there are of course some fundamental differences in 
the approaches taken to implementation, configuration, and usage.

Along with the container services, Spring does include a lot of other 
things, such as integration into the container and interceptor framework 
of a JDBC abstraction layer, some Hibernate support code, transactional 
wrapping, etc. There is also a UI layer which I haven't used so far as I 
prefer Tapestry.

A couple of weeks ago I wrote an article on intergrating Tapestry with 
Spring. It does assume you are already familiar with both frameworks 
however. It's available at:
  http://www.springframework.org/docs/integration/tapestry.html

Regards,
Colin


Harish Krishnaswamy wrote:

> I put the Adder example together with a LoggingInterceptor in three 
> modules and its pretty slick. Although the free form schema gets my 
> head spinning ;). I think it'll take a little bit to get adjusted to 
> living without constraints! I like the fact that it can support both 
> IoC and SoC, nice! And the documentation is great.
>
> I have a few questions:
> 1. What is rationale behind the names <service...> and 
> <extension-point...>? That would probably clarify my confusion with 
> the names. It got me a little confused initially, 
> <service-extension-point...> and <config-extension-point...> is more 
> intuitive to me.
> 2. How to debug deferred services when dynamic proxies are used?
> 3. In the BuilderFactory which service extension point id gets stored 
> in the point-id-property? For example, if I use a LoggingInterceptor 
> like...
>  <extend-service service-id="hivemind.examples.Adder">
>    <interceptor service-id="hivemind.LoggingInterceptor" order="10"/>
>  </extend-service>
>
> Thanks,
> Harish
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tap...@ja...
> For additional commands, e-mail: tap...@ja...
>

[Springframework-developer] A scheduler for Spring?

[Ivan R. <iv...@we...>]

As part of my project I am building a (simple but capable) cron-like
scheduler. Do you think there is a place for it in the Spring
framework?

I think the scheduler itself should be a JavaBean, capable of
executing a given method (with or without parameters) on
an object, according to the supplied schedule.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[Springframework-developer] Mail support

[Kopylenko, D. <dko...@ac...>]

Hello everybody,

Now there is a new mail support in the package org.springframework.mail 

It follows the consistent Spring's template/callback pattern. The central
component is MailTemplate which uses MailSender strategy (which could be
implemented with any email protocol/API) and MailCallback. Typically
mailSender property on the MailTemplate is set through an
ApplicationContext. MailCallback has one method configure() in which the
client's implementation would configure the MailSettings value object with
properties needed to send mail. Also the JavaMailSender implementation is
provided.

Example usage:

MailTemplate mt = new MailTemplate();
MailSender ms = new JavaMailSender();
mt.setMailSender(ms);

mt.sendMail(new MailCallback() {
	public void configure(MailSettings mailSettings) {
			mailSettings.setMailTo("xx...@ya...");
	
mailSettings.setMailFrom("xx...@or...");
			mailSettings.setMailSubject("test");
			mailSettings.setMailText("test");
			mailSettings.setMailHost("localhost");
		}
	});

Regards,
Dmitriy.

Re: [Springframework-developer] Test case failed

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

The ServletException is just from console output in a passing test. I'll
remove it.

This looks like what I see.

Regards,
Rod

----- Original Message -----
From: "Kopylenko, Dmitry" <dko...@su...>
To: "'Rod Johnson'" <rod...@in...>
Sent: Wednesday, September 10, 2003 6:26 PM
Subject: RE: [Springframework-developer] Test case failed


> Rod,
>
> It passed on my work machine (Win XP). It falied on my home machine
(Linux).
> I'll run it at home again. Here is the test report:
>
> Testsuite: org.springframework.beans.factory.xml.XmlBeanFactoryTestSuite
> Tests run: 66, Failures: 0, Errors: 0, Time elapsed: 0.671 sec
> ------------- Standard Error -----------------
> Root cause is javax.servlet.ServletException
> ------------- ---------------- ---------------
>
> Testcase: testFactoryNesting took 0.015 sec
> Testcase: testRefToSeparatePrototypeInstances took 0.016 sec
> Testcase: testRefToSingleton took 0.047 sec
> Testcase: testSingletonInheritanceFromParentFactorySingleton took 0.015
sec
> Testcase: testPrototypeInheritanceFromParentFactoryPrototype took 0.032
sec
> Testcase: testPrototypeInheritanceFromParentFactorySingleton took 0.015
sec
> Testcase: testBogusParentageFromParentFactory took 0.016 sec
> Testcase: testSingletonInheritsFromParentFactoryPrototype took 0.031 sec
> Testcase: testCircularReferences took 0.016 sec
> Testcase: testFactoryReferences took 0 sec
> Testcase: testPrototypeReferences took 0 sec
> Testcase: testFactoryReferenceCircleDoesNotWork took 0.062 sec
> Testcase: testRefSubelement took 0.031 sec
> Testcase: testPropertyWithLiteralValueSubelement took 0.016 sec
> Testcase: testRefSubelementsBuildCollection took 0 sec
> Testcase: testRefSubelementsBuildCollectionFromSingleElement took 0.031
sec
> Testcase: testBuildCollectionFromMixtureOfReferencesAndValues took 0.016
sec
> Testcase: testAutoAliasing took 0 sec
> Testcase: testEmptyMap took 0.016 sec
> Testcase: testMapWithLiteralsOnly took 0.015 sec
> Testcase: testMapWithLiteralsAndReferences took 0.016 sec
> Testcase: testMapWithLiteralsReferencesAndList took 0.015 sec
> Testcase: testEmptyProps took 0 sec
> Testcase: testPopulatedProps took 0.063 sec
> Testcase: testObjectArray took 0.016 sec
> Testcase: testClassArray took 0 sec
> Testcase: testInitMethodIsInvoked took 0.031 sec
> Testcase: testInitMethodThrowsException took 0.015 sec
> Testcase: testNoSuchInitMethod took 0 sec
> Testcase: testInitializingBeanAndInitMethod took 0.016 sec
> Testcase: testNoSuchXmlFile took 0 sec
> Testcase: testInvalidXmlFile took 0.031 sec
> Testcase: testUnsatisfiedObjectDependencyCheck took 0.016 sec
> Testcase: testUnsatisfiedSimpleDependencyCheck took 0 sec
> Testcase: testSatisfiedObjectDependencyCheck took 0.016 sec
> Testcase: testSatisfiedSimpleDependencyCheck took 0.015 sec
> Testcase: testUnsatisfiedAllDependencyCheck took 0 sec
> Testcase: testSatisfiedAllDependencyCheck took 0.016 sec
> Testcase: testSatisfiedAutowireByType took 0 sec
> Testcase: testSatisfiedAutowireByName took 0.015 sec
> Testcase: testCount took 0 sec
> Testcase: testGetDefinitionsForClass took 0 sec
> Testcase: testGetDefinitionsForNoSuchClass took 0 sec
> Testcase: testGetCountForFactoryClass took 0 sec
> Testcase: testInheritance took 0 sec
> Testcase: testGetNull took 0 sec
> Testcase: testInitializingBeanCallback took 0 sec
> Testcase: testLifecycleCallbacks took 0 sec
> Testcase: testFindsValidInstance took 0 sec
> Testcase: testGetInstanceByMatchingClass took 0 sec
> Testcase: testGetInstanceByNonmatchingClass took 0 sec
> Testcase: testGetSharedInstanceByMatchingClass took 0 sec
> Testcase: testGetSharedInstanceByMatchingClassNoCatch took 0 sec
> Testcase: testGetSharedInstanceByNonmatchingClass took 0 sec
> Testcase: testSharedInstancesAreEqual took 0 sec
> Testcase: testNotThere took 0 sec
> Testcase: testValidEmpty took 0 sec
> Testcase: testTypeMismatch took 0 sec
> Testcase: testGrandparentDefinitionFoundInBeanFactory took 0 sec
> Testcase: testFactorySingleton took 0 sec
> Testcase: testFactoryPrototype took 0 sec
> Testcase: testPassthroughFactoryPassesThroughPropertyValues took 0 sec
> Testcase: testGetFactoryItself took 0 sec
> Testcase: testFactoryIsInitialized took 0 sec
> Testcase: testRejectsFactoryGetOnNormalBean took 0 sec
> Testcase: testAliasing took 0 sec
>
> What is this ServletException at the beginning?
>
> D.
>
>
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Wednesday, September 10, 2003 5:12 AM
> To: Kopylenko, Dmitry; spr...@li...
> Subject: Re: [Springframework-developer] Test case failed
>
>
> Dmitriy,
>
> Can you run this test individually to find the specific problem? It runs
for
> me.
>
> Regards,
> Rod
>
> ----- Original Message -----
> From: "Kopylenko, Dmitry" <dko...@su...>
> To: <spr...@li...>
> Sent: Tuesday, September 09, 2003 10:41 PM
> Subject: [Springframework-developer] Test case failed
>
>
> > Hello everybody,
> >
> > I was just running the tests and the build failed because the
> > following
> test
> > case failed:
> >
> > [junit] BUILD FAILED:
> > file:/usr/local/eclipse/workspace/spring/build.xml:276: Test
> > org.springframework.beans.factory.xml.XmlBeanFactoryTestSuite failed
> >
> > Regards,
> > Dmitriy.
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Feature idea

[Rob B. <rob...@ve...>]

Hello all,

In Rod's book he mentions that when your application is deployed in a cluster that you should hold multiple small objects in session instead of one large monolithic object graph.  The reason for this is that the app servers can reduce the amount of data that is replicated for failover by only needing replicate the objects that have changed instead of the entire object graph.

Generally appservers have an optimization where you can specify that only objects that are "added" or "re-added" to a session be replicated.  i.e. You inform the app server that your object's data/state has changed by adding it to session, even if it is already held in session.  By adding it to session with the same name, the original reference is over-written, so only one copy is held in session.  You do the "re-add" specifically to tell the appserver that data has changed in this object, and it's data/state needs to be re-transmitted to the other servers.

It is the developers responsiblity to "inform" the app server by "re-adding" the object to session.  If the developers forgets to do so, the app will still work fine most of the time.  However, when the app does need to failover to the other server you will now run into a problem because the objects data/state modifications did not get replicated.  Policies, code reviews, etc. can all reduce the chances that someone forgets to "re-add" an object to session after modification, but it is still a very simple / easy thing to miss.

How about adding a feature to the spring MVC framework to take care of this automatically.  The "Dirty Marker" pattern can be very helpful here.

Implement an interface:

public interface DirtyMarker {
	
	public static final int NEW = 0;
	public static final int DIRTY = 1;
	public static final int CLEAN = 2;
	
	/**
	 * Returns the dirt state of the object.
	 * @return int - dirt state of object
	 */
	int getDirtState();
	
	/**
	 * Sets the dirt state of the object
	 * @param newState - the new dirt state to set
	 */
	void setDirtState(int newState);
}

I would recommend implementing the interface like this instead of using isNew() isClean() isDirty() because it allows the use of switch/case blocks.

Have any object that you are going to put in session implement this interface.  Your object should have all of it's setter methods call
setDirtState(DIRTY).

Add code to the spring framework so that after the presentation logic implementation is finished it will:
1) loop through all the objects in session
2) check if the object implements DirtyMarker
3) if the object implements DirtyMarker{
      switch(getDirtState()){
         case NEW: setDirtState(CLEAN);  // if NEW, set to CLEAN.
		   break;
         case DIRTY: setDirtState(CLEAN);
                               // set dirtState clean before replication
                               // so it is clean on failover machine
                               // this prevents a replication storm
                               // if failover does happen.
         then "re-add" to session
                   break;
      }
   }

In this way the framework will track if the object should be "re-added" to the session to take advantage of the replication optimization.

Of course, if the object in session has a child object, and you only update the child object, this will not work.  However, you could handle this in design.  Either by design, your objects that get put into session have no child objects, or a parent object can recursively call getDirtState on its child objects from getDirtState. (Do the same for setDirtState)  If anyone returns DIRTY then the parent should return DIRTY.  (Of course, if you are following Rod's advice, these parent-child object graphs will be small, or non-existant).

If you need to put an object into session that does not implement dirty marker, then it's ok, because the framework will check for the interface first and do nothing if the object does not implement the interface.  You can then choose to not use the framework and have to remember to "re-add" the object yourself.  OR, you can use the Decorator pattern to wrap that object inside your own that does implement DirtyMarker.

The one big negative of this approach is that when you first add an object to session it will get transmitted for replication twice.  The first time when you manually add it to session, and the second time when the framework re-adds it to session for you automatically.  You could avoid this by manually setting the object to CLEAN before adding it to session (NEVER DO IT AFTER!  This can cause replication storms on failover).  If you forget to set the object to clean, you take the performance hit of replicating twice, when the object is first added to session, but your failover will still work properly.  Even if you set the object to clean AFTER you add it to session, you may pay a performance hit of a replication storm, but the failover will work!

I haven't yet finished Rod's book (work/life keeps me to busy to read as much as I would like during the day), so I don't know if the framework already does this.  Just thought it would be a good feature.

Also, the DirtyMarker interface is not tied to the web tier so it could be used in command objects too without tying them to the web tier.

What do you think?

Later
Rob

RE: [Springframework-developer] I don't think the way XmlWebApplicationContext finds context is at all portable

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

CT4gT25lIHdheSB0byBoYW5kbGUgdGhpcyB3b3VsZCBiZSB0byBpbXBsZW1lbnQvb3ZlcnJpZGUN
CglnZXRSZXNvdXJjZUFzU3RyZWFtIGluIFhtbFdlYkFwcGxpY2F0aW9uQ29udGV4dCwgaW5zdGVh
ZCBvZiByZWx5aW5nIG9uDQoJdGhlIG9uZSBpbiB0aGUgYWJzdHJhY3QgYmFzZSBjbGFzcy4NCgkN
Cg0KCVRoYXQncyBleGFjdGx5IHdoYXQgWG1sV2ViQXBwbGljYXRpb25Db250ZXh0IGRvZXMgYWxy
ZWFkeTogSXQgb3ZlcnJpZGVzIGdldFJlc291cmNlQnlQYXRoIHRvIGNoZWNrIFNlcnZsZXRDb250
ZXh0LmdldFJlc291cmNlQXNTdHJlYW0uIEVsc2UsIGEgcGF0aCBsaWtlICIvV0VCLUlORi9hcHBs
aWNhdGlvbkNvbnRleHQueG1sIiBiZWxvdyB0aGUgcm9vdCBvZiB0aGUgY3VycmVudCB3ZWIgYXBw
IHdvdWxkIG5vdCB3b3JrIGluIGFueSBzZXJ2bGV0IGNvbnRhaW5lci4NCg0KCUp1ZXJnZW4NCg0K

Re: [Springframework-developer] Partly offline this week

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

Flaky wireless connection in the Canaries? Oh the hardship of it.

I had my appendix out on Sunday. Wireless networking works great for me: I
have a computer on both floors of my house and although I can't walk very
well, I'm never very far from one.

Regards,
Rod

----- Original Message -----
From: "Alef Arendsen (JTeam)" <al...@jt...>
To: <spr...@li...>
Sent: Wednesday, September 10, 2003 9:52 AM
Subject: [Springframework-developer] Partly offline this week


> Hi all,
>
> Maybe you've noticed, but I'm kind of offline this week. I'm sitting on
> a boat on the Canary Islands, and the wireless connection isn't as good
> as it's supposed to be. So next week, I'll be back.
>
> Alef
>
>
> ==
> JTeam B.V.
> Donker Curtiusstraat 7-412
> 1051 JL  Amsterdam
> T: +31 20 486 20 36
> M: +31 6 24 11 1996
> F: +31 84 837 00 00
> E: al...@jt...
> W: www.jteam.nl
>
>

[Springframework-developer] Partly offline this week

[Alef A. \(JTeam\) <al...@jt...>]

Hi all,

Maybe you've noticed, but I'm kind of offline this week. I'm sitting on
a boat on the Canary Islands, and the wireless connection isn't as good
as it's supposed to be. So next week, I'll be back.

Alef


==
JTeam B.V.
Donker Curtiusstraat 7-412
1051 JL  Amsterdam
T: +31 20 486 20 36
M: +31 6 24 11 1996
F: +31 84 837 00 00
E: al...@jt...
W: www.jteam.nl

Re: [Springframework-developer] Test case failed

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

Dmitriy,

Can you run this test individually to find the specific problem? It runs for
me.

Regards,
Rod

----- Original Message -----
From: "Kopylenko, Dmitry" <dko...@su...>
To: <spr...@li...>
Sent: Tuesday, September 09, 2003 10:41 PM
Subject: [Springframework-developer] Test case failed


> Hello everybody,
>
> I was just running the tests and the build failed because the following
test
> case failed:
>
> [junit] BUILD FAILED:
> file:/usr/local/eclipse/workspace/spring/build.xml:276: Test
> org.springframework.beans.factory.xml.XmlBeanFactoryTestSuite failed
>
> Regards,
> Dmitriy.
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] API simplification

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

Rod & All,

I'm all for simplifying the API and while working on refactoring the
StoredProcedure to use JdbcTemplate I've come across two issues.

1. Does anybody use the ParameterMapper interface defined in the StoredProcedure
class?  I would like to remove it.  With the new implementation for
StoredProcedures, that mimics how we create PreparedStatements, there will be
other ways of providing database specific ways to map parameters.

2.  For PreparedStatements there are two ways of setting the parameters.  Either
using a PreparedStatementCreatorFactory or a PreparedStetementSetter.  Which
method are you all preferring?  Should we pick one, or should the
CallableStatement implementation provide both ways as well?

Let me know what you think.

Also, do you want me to just commit any changes to the jdbc package, or do you
want me to create a separate branch so we can make sure it really works before
we merge it in to the main branch?  I'm making sure the tests run and I test
with some live connections, but with the variety of JDBC drivers and databases
out there, I can only test on a small subset of all the possible combinations.

Thomas

> I've just committed another BeanFactory change. This removes the
> getPropertyValues() method from the FactoryBean interface. This makes life
> easier for typical development usage. Developers won't need to understand
> the (slightly obscure) purpose of this method unless they want to, in which
> case they implement the new PropertiesValueProviderFactoryBean interface.
> 
> As all FactoryBean implementations in the src tree, as opposed to the test
> tree, don't use pass through properties, I removed the getPropertyValues()
> method from all of them.
> 
> Regards,
> Rod
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

[Springframework-developer] Test case failed

[Kopylenko, D. <dko...@ac...>]

Hello everybody,

I was just running the tests and the build failed because the following test
case failed:

[junit] BUILD FAILED:
file:/usr/local/eclipse/workspace/spring/build.xml:276: Test
org.springframework.beans.factory.xml.XmlBeanFactoryTestSuite failed

Regards,
Dmitriy.

[Springframework-developer] JDBC Changes

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

Rod & All,

I posted this message earlier today, but it does not seem to have made it to the
list, so I am posting it again.

1. Does anybody use the ParameterMapper interface defined in the StoredProcedure
class?  I would like to remove it.  With the new implementation for
StoredProcedures, that mimics how we create PreparedStatements, there will be
other ways of providing database specific ways to map parameters.

2.  For PreparedStatements there are two ways of setting the parameters.  Either
using a PreparedStatementCreatorFactory or a PreparedStetementSetter.  Which
method are you all preferring?  Should we pick one, or should the
CallableStatement implementation provide both ways as well?

Let me know what you think.

Also, do you want me to just commit any changes to the jdbc package, or do you
want me to create a separate branch so we can make sure it really works before
we merge it in to the main branch?  I'm making sure the tests run and I test
with some live connections, but with the variety of JDBC drivers and databases
out there, I can only test on a small subset of all the possible combinations.

Thomas

Re: [Springframework-developer] Sad but true, was Another BeanFactory feature

[Rob B. <rob...@ve...>]

Last comment:

A wise man once said:

"A framework should be easy to use.  Unduly complex frameworks will be
ignored by developers, and create problems of their own.  Irrelevant, or
seldom-used, capabilities are a key danger.  The Pareto Principle is
particularly relevant to framework design.  Often it's best to settle for a
simple solution to most problems than a comprehensive, but complex solution
that makes many tasks harder than they should be (J2EE arguably falls into
the latter category)."

Rod Johnson - Expert one-on-one J2EE Design and Development pg396 paragraph
5

I agree that many open source projects die because of "marketing" problems.
I don't want that to happen to spring either,  because I hope to use it in
future projects of my own and want it to be a well supported framework with
a thriving community.  I'm perfectly fine with this feature being added to
spring.  I also don't want to seem the black sheep / black cloud, and I
think that it appears I may have come off that way..  Please excuse me if
that is the case.  I only ask that the Pareto Principle be kept in mind when
adding any "feature" only for the purposes of "marketing".  It can also be
considered a "feature" to not include capabilities that are "Irrelevent, or
seldom-used" or that the project developers "don't really recommend".

There are a few way to compete on the "marketing" front.  We can all jump
off the bridge because the PicoContainer does.  We can all forget spring
completely and use entity beans and struts because "everyone else does".  Or
we can say, no, we don't do xxx or yyy because doing things that way is bad.
We do it this way instead because it's better.  Let us show you how and why
it's better.

Again, I'm fine with this particular "feature".  I just concerned it will be
one of the first "features" to sneak in for marketing and then set a
precendence.  It's always harder to close the door once it's open.  It's
also harder to "remove" a feature because "no one" uses it.  Someone,
somewhere will use it, and then when it's removed complain like crazy.

AS for the "global switch".  My thoughts behind that were to offer some sort
of "strict" capability, where any of the features that are not recommended
can be shut off as a group.  This would prevent a developer from
inadvertantly using any feature (not just this one) that is not recommended.
Kind of along the lines of the XHTML strict / transitional option.  The same
thing could probably be implemented by having two DTD's for Spring.  One
that has all the "added for marketing" stuff, and one that has only the
recommended stuff.  Doing things in this manner would require no code
changes to Spring itself, and still have the advantage of preventing the use
of "marketing" features accidentally by developers - as long as the
developer verifies their XML against the DTD. If you feel it's not needed
though, I'm cool with it.

Later
Rob

> I understand some concerns about this feature.
>
> Rob, I don't think it needs to have a global switch to turn it off. It's
off
> by default. It's off if you don't know it's there or don't want to. The
only
> way to turn it on involves adding an optional attribute to each bean that
> uses it. It's backward compatible. It doesn't complicate the API (no more
> public methods on classes application developers will use).
>
> Secondly, if no one uses it and it ends up being only for marketing, I'll
> happily get rid of it. I believe we should be ruthless with features no
one
> uses. Hibernate get this right.
>
> Marketing: I agree it's sad. But there are a lot of good open source
> projects that don't go anywhere, meaning it doesn't matter how good they
> are. I don't want Spring to be like that. I think our architecture is
> particularly good, we have an advantage in my public profile and the fact
> that many of us regularly contribute to TSS etc, but we need to consider
> marketing.
>
> Nevertheless, I would never want to do anything that compromises our
> architecture. I don't think this feature does.
>
> >While I'm sure most of us are very talented developers,
> almost everyone I talk to always comments on the programmers who can't
> figure out how to turn on a light switch.
>
> I used to think that. But I'm starting to wonder if we aren't all being a
> bit naive here. Maybe it's just the market, but I've found that I can hire
> good developers in London who are capable of working things out for
> themselves. Of course I have to interview 2-3 others before I employ one,
> but there are a lot of good Java developers out there.
>
> Regards,
> Rod
>
>
> ----- Original Message -----
> From: "Trevor Cook" <pr...@se...>
> To: <spr...@li...>
> Sent: Friday, September 05, 2003 9:20 PM
> Subject: RE: [Springframework-developer] Sad but true, was Another
> BeanFactory feature
>
>
> I think it's a great idea, partly for marketing but more for an easier
> "entry-level" use.  While I'm sure most of us are very talented
developers,
> almost everyone I talk to always comments on the programmers who can't
> figure out how to turn on a light switch.  Making Spring easier for those
> who don't have the time or expertise to figure out the details of the
> framework are more likely to adopt if most of the little stuff is taken
care
> of (like the "automagical wiring").  I also see broad acceptance of Spring
> being of big value, since that provides more use/testing in the real
world,
> and because a larger market of users will naturally draw more developers,
> thus improving Spring even more.
>
> With that in mind, I personally wouldn't mind seeing auto-wiring ON by
> default.  I would not use it, and (I'm assuming) most of the developers
I've
> talked to from the Spring project wouldn't use it.  However, if those with
> the time/experience to fully understand how to use/configure Spring are in
> the minority (which I expect they will be if we have a large user base),
> wouldn't it make more sense to have the defaults at a "beginner" level to
> handle the 80% of users, rather than "advanced" to support the 20% (which
> then forces the 80% to do more digging/searching, and often going
> elsewhere).
>
> I also wouldn't say I wouldn't recommend using the autowiring.  If I'm
doind
> an important, enterprise level system, I definately want to control
exactly
> what's going on, and I will probably have a more complex context.
However,
> for all the "one-off" standalone apps, internal web sites, and prototypes,
> you simply don't need to manually code stuff, and even the "advanced"
> developer might use the auto-wiring.
>
> +1 to adding it with either default setting (but I'd lean to "beginner"
> defaults)
>
> T
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Rob Butler
> Sent: September 5, 2003 12:30 PM
> To: Jean-Pierre; 'Rod Johnson'; 'Ivan Ristic'
> Cc: spr...@li...
> Subject: [Springframework-developer] Sad but true, was Another
> BeanFactory feature
>
>
> Sad but true (Metallica)
>
> It's pretty sad when an open source, well architected project has to add
> features that are of little use or ones that they "don't really recommend"
> for "marketing" value.  I know it's true that open source projects need to
> be concerned as much with marketing these days as commercial software.
It's
> just sad to have it be so true, since many open source projects are
attempts
> to get away from the marketing and hype and deliver a quality (free)
> technically superior piece software.
>
> Back to the matter at hand, I can see the value in having the
"automagical"
> wiring, and I can also see the value in not having the automagical stuff.
> How about adding a feature to the framework that ALL the automagical stuff
> can be declaritively turned on/off(disabled) with just one setting, by
> default it is off(disabled).  In that way, any attempt to use the
> automagical features in the config files throws an error on startup.  Also
> "autowiring", etc would be disabled.  This (I think) would make both
crowds
> happy because those who want automagical stuff can use it, they would just
> specifically have to turn it ON for the framework before using the
> automagical features in code / config files.  Those who don't can leave it
> turned off.
>
> Later
> Rob
>
>
> +1
>
> I agree it's not really to recommend. But marketing has to be taken in
> account.
>
> Jean-Pierre
>
> -----Message d'origine-----
> De : spr...@li...
> [mailto:spr...@li...] De la
> part de Rod Johnson
> Envoyé : jeudi 4 septembre 2003 23:42
> À : Ivan Ristic
> Cc : spr...@li...
> Objet : Re: [Springframework-developer] Another BeanFactory feature
>
> >    In a way, wiring the beans manually is a form of documentation
> >    how system works. So, if it were up to me I would cancel all
> >    automagical processes. Besides, we will probably soon have GUI
> >    tools to configure our beans with and that will be more fun
> >    anyway.
>
> I'm inclined to agree. But I think the marketing advantage is real, as
> the
> "objects cannot be in an inconsistent state" argument is the only thing
> PicoContainer can really claim as an advantage over Spring. Even if we
> don't
> use it, and don't really recommend it, this neutralizes that claim.
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] API simplification

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

I've just committed another BeanFactory change. This removes the
getPropertyValues() method from the FactoryBean interface. This makes life
easier for typical development usage. Developers won't need to understand
the (slightly obscure) purpose of this method unless they want to, in which
case they implement the new PropertiesValueProviderFactoryBean interface.

As all FactoryBean implementations in the src tree, as opposed to the test
tree, don't use pass through properties, I removed the getPropertyValues()
method from all of them.

Regards,
Rod

Re: [Springframework-developer] Autowire

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

Rod,

> Thomas, the DTD needs to be uploaded again. I've added an explanation of the
> feature in the DTD.
> 

It's there now!

Thomas

Re: [Springframework-developer] Autowire

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

I've now committed autowire. It's off by default, and can only be switched
on at individual bean level. So you won't notice any change unless you
choose to use it.

I've made a big effort to make the error messages helpful, so that people
will have some idea what happens if autowiring is going wrong.

Thomas, the DTD needs to be uploaded again. I've added an explanation of the
feature in the DTD.

Regards,
Rod

----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: "Trevor Cook" <pr...@se...>;
<spr...@li...>
Sent: Saturday, September 06, 2003 8:27 AM
Subject: Re: [Springframework-developer] Sad but true, was Another
BeanFactory feature


> I understand some concerns about this feature.
>
> Rob, I don't think it needs to have a global switch to turn it off. It's
off
> by default. It's off if you don't know it's there or don't want to. The
only
> way to turn it on involves adding an optional attribute to each bean that
> uses it. It's backward compatible. It doesn't complicate the API (no more
> public methods on classes application developers will use).
>
> Secondly, if no one uses it and it ends up being only for marketing, I'll
> happily get rid of it. I believe we should be ruthless with features no
one
> uses. Hibernate get this right.
>
> Marketing: I agree it's sad. But there are a lot of good open source
> projects that don't go anywhere, meaning it doesn't matter how good they
> are. I don't want Spring to be like that. I think our architecture is
> particularly good, we have an advantage in my public profile and the fact
> that many of us regularly contribute to TSS etc, but we need to consider
> marketing.
>
> Nevertheless, I would never want to do anything that compromises our
> architecture. I don't think this feature does.
>
> >While I'm sure most of us are very talented developers,
> almost everyone I talk to always comments on the programmers who can't
> figure out how to turn on a light switch.
>
> I used to think that. But I'm starting to wonder if we aren't all being a
> bit naive here. Maybe it's just the market, but I've found that I can hire
> good developers in London who are capable of working things out for
> themselves. Of course I have to interview 2-3 others before I employ one,
> but there are a lot of good Java developers out there.
>
> Regards,
> Rod
>
>
> ----- Original Message -----
> From: "Trevor Cook" <pr...@se...>
> To: <spr...@li...>
> Sent: Friday, September 05, 2003 9:20 PM
> Subject: RE: [Springframework-developer] Sad but true, was Another
> BeanFactory feature
>
>
> I think it's a great idea, partly for marketing but more for an easier
> "entry-level" use.  While I'm sure most of us are very talented
developers,
> almost everyone I talk to always comments on the programmers who can't
> figure out how to turn on a light switch.  Making Spring easier for those
> who don't have the time or expertise to figure out the details of the
> framework are more likely to adopt if most of the little stuff is taken
care
> of (like the "automagical wiring").  I also see broad acceptance of Spring
> being of big value, since that provides more use/testing in the real
world,
> and because a larger market of users will naturally draw more developers,
> thus improving Spring even more.
>
> With that in mind, I personally wouldn't mind seeing auto-wiring ON by
> default.  I would not use it, and (I'm assuming) most of the developers
I've
> talked to from the Spring project wouldn't use it.  However, if those with
> the time/experience to fully understand how to use/configure Spring are in
> the minority (which I expect they will be if we have a large user base),
> wouldn't it make more sense to have the defaults at a "beginner" level to
> handle the 80% of users, rather than "advanced" to support the 20% (which
> then forces the 80% to do more digging/searching, and often going
> elsewhere).
>
> I also wouldn't say I wouldn't recommend using the autowiring.  If I'm
doind
> an important, enterprise level system, I definately want to control
exactly
> what's going on, and I will probably have a more complex context.
However,
> for all the "one-off" standalone apps, internal web sites, and prototypes,
> you simply don't need to manually code stuff, and even the "advanced"
> developer might use the auto-wiring.
>
> +1 to adding it with either default setting (but I'd lean to "beginner"
> defaults)
>
> T
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Rob Butler
> Sent: September 5, 2003 12:30 PM
> To: Jean-Pierre; 'Rod Johnson'; 'Ivan Ristic'
> Cc: spr...@li...
> Subject: [Springframework-developer] Sad but true, was Another
> BeanFactory feature
>
>
> Sad but true (Metallica)
>
> It's pretty sad when an open source, well architected project has to add
> features that are of little use or ones that they "don't really recommend"
> for "marketing" value.  I know it's true that open source projects need to
> be concerned as much with marketing these days as commercial software.
It's
> just sad to have it be so true, since many open source projects are
attempts
> to get away from the marketing and hype and deliver a quality (free)
> technically superior piece software.
>
> Back to the matter at hand, I can see the value in having the
"automagical"
> wiring, and I can also see the value in not having the automagical stuff.
> How about adding a feature to the framework that ALL the automagical stuff
> can be declaritively turned on/off(disabled) with just one setting, by
> default it is off(disabled).  In that way, any attempt to use the
> automagical features in the config files throws an error on startup.  Also
> "autowiring", etc would be disabled.  This (I think) would make both
crowds
> happy because those who want automagical stuff can use it, they would just
> specifically have to turn it ON for the framework before using the
> automagical features in code / config files.  Those who don't can leave it
> turned off.
>
> Later
> Rob
>
>
> +1
>
> I agree it's not really to recommend. But marketing has to be taken in
> account.
>
> Jean-Pierre
>
> -----Message d'origine-----
> De : spr...@li...
> [mailto:spr...@li...] De la
> part de Rod Johnson
> Envoyé : jeudi 4 septembre 2003 23:42
> À : Ivan Ristic
> Cc : spr...@li...
> Objet : Re: [Springframework-developer] Another BeanFactory feature
>
> >    In a way, wiring the beans manually is a form of documentation
> >    how system works. So, if it were up to me I would cancel all
> >    automagical processes. Besides, we will probably soon have GUI
> >    tools to configure our beans with and that will be more fun
> >    anyway.
>
> I'm inclined to agree. But I think the marketing advantage is real, as
> the
> "objects cannot be in an inconsistent state" argument is the only thing
> PicoContainer can really claim as an advantage over Spring. Even if we
> don't
> use it, and don't really recommend it, this neutralizes that claim.
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Sad but true, was Another BeanFactory feature

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

I understand some concerns about this feature.

Rob, I don't think it needs to have a global switch to turn it off. It's off
by default. It's off if you don't know it's there or don't want to. The only
way to turn it on involves adding an optional attribute to each bean that
uses it. It's backward compatible. It doesn't complicate the API (no more
public methods on classes application developers will use).

Secondly, if no one uses it and it ends up being only for marketing, I'll
happily get rid of it. I believe we should be ruthless with features no one
uses. Hibernate get this right.

Marketing: I agree it's sad. But there are a lot of good open source
projects that don't go anywhere, meaning it doesn't matter how good they
are. I don't want Spring to be like that. I think our architecture is
particularly good, we have an advantage in my public profile and the fact
that many of us regularly contribute to TSS etc, but we need to consider
marketing.

Nevertheless, I would never want to do anything that compromises our
architecture. I don't think this feature does.

>While I'm sure most of us are very talented developers,
almost everyone I talk to always comments on the programmers who can't
figure out how to turn on a light switch.

I used to think that. But I'm starting to wonder if we aren't all being a
bit naive here. Maybe it's just the market, but I've found that I can hire
good developers in London who are capable of working things out for
themselves. Of course I have to interview 2-3 others before I employ one,
but there are a lot of good Java developers out there.

Regards,
Rod


----- Original Message -----
From: "Trevor Cook" <pr...@se...>
To: <spr...@li...>
Sent: Friday, September 05, 2003 9:20 PM
Subject: RE: [Springframework-developer] Sad but true, was Another
BeanFactory feature


I think it's a great idea, partly for marketing but more for an easier
"entry-level" use.  While I'm sure most of us are very talented developers,
almost everyone I talk to always comments on the programmers who can't
figure out how to turn on a light switch.  Making Spring easier for those
who don't have the time or expertise to figure out the details of the
framework are more likely to adopt if most of the little stuff is taken care
of (like the "automagical wiring").  I also see broad acceptance of Spring
being of big value, since that provides more use/testing in the real world,
and because a larger market of users will naturally draw more developers,
thus improving Spring even more.

With that in mind, I personally wouldn't mind seeing auto-wiring ON by
default.  I would not use it, and (I'm assuming) most of the developers I've
talked to from the Spring project wouldn't use it.  However, if those with
the time/experience to fully understand how to use/configure Spring are in
the minority (which I expect they will be if we have a large user base),
wouldn't it make more sense to have the defaults at a "beginner" level to
handle the 80% of users, rather than "advanced" to support the 20% (which
then forces the 80% to do more digging/searching, and often going
elsewhere).

I also wouldn't say I wouldn't recommend using the autowiring.  If I'm doind
an important, enterprise level system, I definately want to control exactly
what's going on, and I will probably have a more complex context.  However,
for all the "one-off" standalone apps, internal web sites, and prototypes,
you simply don't need to manually code stuff, and even the "advanced"
developer might use the auto-wiring.

+1 to adding it with either default setting (but I'd lean to "beginner"
defaults)

T


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rob Butler
Sent: September 5, 2003 12:30 PM
To: Jean-Pierre; 'Rod Johnson'; 'Ivan Ristic'
Cc: spr...@li...
Subject: [Springframework-developer] Sad but true, was Another
BeanFactory feature


Sad but true (Metallica)

It's pretty sad when an open source, well architected project has to add
features that are of little use or ones that they "don't really recommend"
for "marketing" value.  I know it's true that open source projects need to
be concerned as much with marketing these days as commercial software.  It's
just sad to have it be so true, since many open source projects are attempts
to get away from the marketing and hype and deliver a quality (free)
technically superior piece software.

Back to the matter at hand, I can see the value in having the "automagical"
wiring, and I can also see the value in not having the automagical stuff.
How about adding a feature to the framework that ALL the automagical stuff
can be declaritively turned on/off(disabled) with just one setting, by
default it is off(disabled).  In that way, any attempt to use the
automagical features in the config files throws an error on startup.  Also
"autowiring", etc would be disabled.  This (I think) would make both crowds
happy because those who want automagical stuff can use it, they would just
specifically have to turn it ON for the framework before using the
automagical features in code / config files.  Those who don't can leave it
turned off.

Later
Rob


+1

I agree it's not really to recommend. But marketing has to be taken in
account.

Jean-Pierre

-----Message d'origine-----
De : spr...@li...
[mailto:spr...@li...] De la
part de Rod Johnson
Envoyé : jeudi 4 septembre 2003 23:42
À : Ivan Ristic
Cc : spr...@li...
Objet : Re: [Springframework-developer] Another BeanFactory feature

>    In a way, wiring the beans manually is a form of documentation
>    how system works. So, if it were up to me I would cancel all
>    automagical processes. Besides, we will probably soon have GUI
>    tools to configure our beans with and that will be more fun
>    anyway.

I'm inclined to agree. But I think the marketing advantage is real, as
the
"objects cannot be in an inconsistent state" argument is the only thing
PicoContainer can really claim as an advantage over Spring. Even if we
don't
use it, and don't really recommend it, this neutralizes that claim.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer






-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Sad but true, was Another BeanFactory feature

[Trevor C. <pr...@se...>]

I think it's a great idea, partly for marketing but more for an easier
"entry-level" use.  While I'm sure most of us are very talented developer=
s,
almost everyone I talk to always comments on the programmers who can't
figure out how to turn on a light switch.  Making Spring easier for those
who don't have the time or expertise to figure out the details of the
framework are more likely to adopt if most of the little stuff is taken c=
are
of (like the "automagical wiring").  I also see broad acceptance of Sprin=
g
being of big value, since that provides more use/testing in the real worl=
d,
and because a larger market of users will naturally draw more developers,
thus improving Spring even more.

With that in mind, I personally wouldn't mind seeing auto-wiring ON by
default.  I would not use it, and (I'm assuming) most of the developers I=
've
talked to from the Spring project wouldn't use it.  However, if those wit=
h
the time/experience to fully understand how to use/configure Spring are i=
n
the minority (which I expect they will be if we have a large user base),
wouldn't it make more sense to have the defaults at a "beginner" level to
handle the 80% of users, rather than "advanced" to support the 20% (which
then forces the 80% to do more digging/searching, and often going
elsewhere).

I also wouldn't say I wouldn't recommend using the autowiring.  If I'm do=
ind
an important, enterprise level system, I definately want to control exact=
ly
what's going on, and I will probably have a more complex context.  Howeve=
r,
for all the "one-off" standalone apps, internal web sites, and prototypes=
,
you simply don't need to manually code stuff, and even the "advanced"
developer might use the auto-wiring.

+1 to adding it with either default setting (but I'd lean to "beginner"
defaults)

T


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rob Butler
Sent: September 5, 2003 12:30 PM
To: Jean-Pierre; 'Rod Johnson'; 'Ivan Ristic'
Cc: spr...@li...
Subject: [Springframework-developer] Sad but true, was Another
BeanFactory feature


Sad but true (Metallica)

It's pretty sad when an open source, well architected project has to add
features that are of little use or ones that they "don't really recommend=
"
for "marketing" value.  I know it's true that open source projects need t=
o
be concerned as much with marketing these days as commercial software.  I=
t's
just sad to have it be so true, since many open source projects are attem=
pts
to get away from the marketing and hype and deliver a quality (free)
technically superior piece software.

Back to the matter at hand, I can see the value in having the "automagica=
l"
wiring, and I can also see the value in not having the automagical stuff.
How about adding a feature to the framework that ALL the automagical stuf=
f
can be declaritively turned on/off(disabled) with just one setting, by
default it is off(disabled).  In that way, any attempt to use the
automagical features in the config files throws an error on startup.  Als=
o
"autowiring", etc would be disabled.  This (I think) would make both crow=
ds
happy because those who want automagical stuff can use it, they would jus=
t
specifically have to turn it ON for the framework before using the
automagical features in code / config files.  Those who don't can leave i=
t
turned off.

Later
Rob


+1

I agree it's not really to recommend. But marketing has to be taken in
account.

Jean-Pierre

-----Message d'origine-----
De : spr...@li...
[mailto:spr...@li...] De la
part de Rod Johnson
Envoy=E9 : jeudi 4 septembre 2003 23:42
=C0 : Ivan Ristic
Cc : spr...@li...
Objet : Re: [Springframework-developer] Another BeanFactory feature

>    In a way, wiring the beans manually is a form of documentation
>    how system works. So, if it were up to me I would cancel all
>    automagical processes. Besides, we will probably soon have GUI
>    tools to configure our beans with and that will be more fun
>    anyway.

I'm inclined to agree. But I think the marketing advantage is real, as
the
"objects cannot be in an inconsistent state" argument is the only thing
PicoContainer can really claim as an advantage over Spring. Even if we
don't
use it, and don't really recommend it, this neutralizes that claim.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer






-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Sad but true, was Another BeanFactory feature

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

To reverse the old adage, 'one man's poison is another man's meat'. I 
honestly don't think that what you're describing is possible, since 
different things are of different value to different people. On top of 
that, Spring is made up of various components, so it's hard to do 
something such as cut out a swath of functionality across the whole thing.

At the end of the day, I think as the project (any project really) 
devleops, you have to constantly look at the value of the new features 
you are adding (and there is more than one way to define value), decide 
whether they are worth having at all, and try to come up with some 
sensible defaults and usage and configuration mechanisms that achieve 
the right balance in all these aspects such as ease of use, power, 
reliability, marketing, etc. I know this is vague, but I really think it 
has to be done on a case by case basis, and handled in that fashion it 
is manageable and possible.

Regards,
Colin


Rob Butler wrote:

>Sad but true (Metallica)
>
>It's pretty sad when an open source, well architected project has to add
>features that are of little use or ones that they "don't really recommend"
>for "marketing" value.  I know it's true that open source projects need to
>be concerned as much with marketing these days as commercial software.  It's
>just sad to have it be so true, since many open source projects are attempts
>to get away from the marketing and hype and deliver a quality (free)
>technically superior piece software.
>
>Back to the matter at hand, I can see the value in having the "automagical"
>wiring, and I can also see the value in not having the automagical stuff.
>How about adding a feature to the framework that ALL the automagical stuff
>can be declaritively turned on/off(disabled) with just one setting, by
>default it is off(disabled).  In that way, any attempt to use the
>automagical features in the config files throws an error on startup.  Also
>"autowiring", etc would be disabled.  This (I think) would make both crowds
>happy because those who want automagical stuff can use it, they would just
>specifically have to turn it ON for the framework before using the
>automagical features in code / config files.  Those who don't can leave it
>turned off.
>
>Later
>Rob
>
>
>+1
>
>I agree it's not really to recommend. But marketing has to be taken in
>account.
>
>Jean-Pierre
>
>-----Message d'origine-----
>De : spr...@li...
>[mailto:spr...@li...] De la
>part de Rod Johnson
>Envoyé : jeudi 4 septembre 2003 23:42
>À : Ivan Ristic
>Cc : spr...@li...
>Objet : Re: [Springframework-developer] Another BeanFactory feature
>
>  
>
>>   In a way, wiring the beans manually is a form of documentation
>>   how system works. So, if it were up to me I would cancel all
>>   automagical processes. Besides, we will probably soon have GUI
>>   tools to configure our beans with and that will be more fun
>>   anyway.
>>    
>>
>
>I'm inclined to agree. But I think the marketing advantage is real, as
>the
>"objects cannot be in an inconsistent state" argument is the only thing
>PicoContainer can really claim as an advantage over Spring. Even if we
>don't
>use it, and don't really recommend it, this neutralizes that claim.
>
>  
>

[Springframework-developer] Sad but true, was Another BeanFactory feature

[Rob B. <rob...@ve...>]

Sad but true (Metallica)

It's pretty sad when an open source, well architected project has to add
features that are of little use or ones that they "don't really recommend"
for "marketing" value.  I know it's true that open source projects need to
be concerned as much with marketing these days as commercial software.  It's
just sad to have it be so true, since many open source projects are attempts
to get away from the marketing and hype and deliver a quality (free)
technically superior piece software.

Back to the matter at hand, I can see the value in having the "automagical"
wiring, and I can also see the value in not having the automagical stuff.
How about adding a feature to the framework that ALL the automagical stuff
can be declaritively turned on/off(disabled) with just one setting, by
default it is off(disabled).  In that way, any attempt to use the
automagical features in the config files throws an error on startup.  Also
"autowiring", etc would be disabled.  This (I think) would make both crowds
happy because those who want automagical stuff can use it, they would just
specifically have to turn it ON for the framework before using the
automagical features in code / config files.  Those who don't can leave it
turned off.

Later
Rob


+1

I agree it's not really to recommend. But marketing has to be taken in
account.

Jean-Pierre

-----Message d'origine-----
De : spr...@li...
[mailto:spr...@li...] De la
part de Rod Johnson
Envoyé : jeudi 4 septembre 2003 23:42
À : Ivan Ristic
Cc : spr...@li...
Objet : Re: [Springframework-developer] Another BeanFactory feature

>    In a way, wiring the beans manually is a form of documentation
>    how system works. So, if it were up to me I would cancel all
>    automagical processes. Besides, we will probably soon have GUI
>    tools to configure our beans with and that will be more fun
>    anyway.

I'm inclined to agree. But I think the marketing advantage is real, as
the
"objects cannot be in an inconsistent state" argument is the only thing
PicoContainer can really claim as an advantage over Spring. Even if we
don't
use it, and don't really recommend it, this neutralizes that claim.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer






-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Throwing HTTP status 404 instead of exceptions in

[Ivan R. <iv...@we...>]

> Personally the ServletException thrown by MultiActionController in the case
> of missing request handling method does not bother me. IMO the
> DispatcherServlet is a generic "front controller" servlet which could be
> parameterized with different HandlerAdaptors and should not care about
> specifics of any particular handler. So I guess it's ok for the
> DispatcherServlet to "get" ServletExceptions with "wrapped" exeptions from
> handlers.

   This is a special case. With handlers we are in effect creating a
   virtual file system (from a point of view of the web server). So it
   is semantically correct to return a "not found" message.

   It isn't a big deal, since you can always inherit the servlet and
   override the method but to me feels natural.


 > DispatcherServlet to "get" ServletExceptions with "wrapped" exeptions from
 > handlers.

   I somehow managed to overlook the fact that the
   NoSuchRequestHandlingMethodException exception is actually wrapped inside
   the ServletException. Obviously, that is good enough as far as propagation
   is concerned.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

RE: [Springframework-developer] Throwing HTTP status 404 instead of exceptions in

[Kopylenko, D. <dko...@ac...>]

Ivan,

Personally the ServletException thrown by MultiActionController in the case
of missing request handling method does not bother me. IMO the
DispatcherServlet is a generic "front controller" servlet which could be
parameterized with different HandlerAdaptors and should not care about
specifics of any particular handler. So I guess it's ok for the
DispatcherServlet to "get" ServletExceptions with "wrapped" exeptions from
handlers. Besides the NoSuchRequestHandlingMethodException does a good job
in terms of info message:

public NoSuchRequestHandlingMethodException(String name,
MultiActionController multiActionRequestController) {
		super(
			"No request handling method with name '" + name + "'
in class " + multiActionRequestController.getClass().getName());
			this.name = name;
		}
}

May be I'm wrong. Any other opinions on this?

Regards,
Dmitriy.

-----Original Message-----
From: Ivan Ristic [mailto:iv...@we...] 
Sent: Friday, September 05, 2003 7:45 AM
To: spr...@li...
Subject: [Springframework-developer] Throwing HTTP status 404 instead of
exceptions in



Right now, when a MultiActionController can't find the handler for the
request it throws an instance of ServletException. This exception is then
propagated back to the user.

I propose that we change this exception into a HTTP 404 Not found error
(which makes perfect sense to me). Or even better, allow the servlet to make
that decision. Something along the lines of letting the
NoSuchRequestHandlingMethodException (or some alternative
exception) propagate to reach the servlet, which could catch it if it wants
to.


A part of MultiActionController.java:

try {
   String name = methodNameResolver.getHandlerMethodName(request);
   return invokeNamedMethod(name, request, response);
}
   catch (NoSuchRequestHandlingMethodException ex) {
   throw new ServletException("No handler", ex);
}

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Throwing HTTP status 404 instead of exceptions in

[Ivan R. <iv...@we...>]

Right now, when a MultiActionController can't find the handler
for the request it throws an instance of ServletException. This
exception is then propagated back to the user.

I propose that we change this exception into a HTTP 404 Not found
error (which makes perfect sense to me). Or even better, allow the
servlet to make that decision. Something along the lines of
letting the NoSuchRequestHandlingMethodException (or some alternative
exception) propagate to reach the servlet, which could catch it if
it wants to.


A part of MultiActionController.java:

try {
   String name = methodNameResolver.getHandlerMethodName(request);
   return invokeNamedMethod(name, request, response);
}
   catch (NoSuchRequestHandlingMethodException ex) {
   throw new ServletException("No handler", ex);
}

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[Springframework-developer] =?iso-8859-1?Q?RE:_[Springframework-developer]_MutableSortDefinition?=

[=?iso-8859-1?Q?<jp....@ti...>]

Juergen,=0D=0A=0D=0AI don't know if I should make even it's very thin.=0D=
=0A=0D=0AAs the MutableSortDefinition can by highly subclassed (no final =
methods, ...), I simply for now subclassed in a personal CustomSortDefini=
tion which adds the constructor. I use systematically my own subclass. =0D=
=0A=0D=0AIn summary, I don't know if my need is really general to resolve=
 it in the base Class. I think yes as a simple way to initialize a new so=
rt definition is useful. But as a personal way was found, I wait for more=
 advices before re-putting it.=0D=0A=0D=0AJean-Pierre=0D=0A=0D=0A--------=
-- Initial Header -----------=0D=0A=0D=0AFrom      : springframework-deve=
lop...@li...=0D=0ATo          : "JP Pawlak" <jp.pawl=
ak...@ti...>,<spr...@li...>=0D=0ACc =
         : =0D=0ADate      : Fri, 5 Sep 2003 12:49:56 +0200=0D=0ASubject =
: RE: [Springframework-developer] MutableSortDefinition=0D=0A=0D=0AFeel f=
ree to re/add it if you actually need it - I fixed bug in the sort defini=
tion dirty detection via a copy constructor instead of reflection-based p=
roperty copying (only occured on certain JDKs like Sun 1.3.1).=0D=0A =0D=0A=
Juergen=0D=0A(yes, I admit it, reading my emails from an Internet termina=
l in Australia ;-)=0D=0A =0D=0A=0D=0A	-----Original Message----- =0D=0A	F=
rom: JP Pawlak [mailto:jp....@ti...] =0D=0A	Sent: Sat 8/30/2003 2=
:44 PM =0D=0A	To: spr...@li... =0D=0A	=
Cc: =0D=0A	Subject: [Springframework-developer] MutableSortDefinition=0D=0A=
	=0D=0A	=0D=0A=0D=0A	Juergen,=0D=0A	=0D=0A	Is it a reason for which the M=
utableSortDefinition has no more a=0D=0A	constructor with its properties =
(property, ascending, ignoreCase and=0D=0A	eventually which was not on th=
e previous constructor=0D=0A	toggleAscendingOnProperty)?=0D=0A	It's now i=
nstead a constructor taking a base sort definition that don't=0D=0A	help =
me.=0D=0A	=0D=0A	It was simpler to create sort definitions.=0D=0A	=0D=0A	=
SortDefinition soertDef =3D new MutableSortDef(...);=0D=0A	=0D=0A	Has now=
 to be replaced by=0D=0A	=0D=0A	SortDefinition soertDef;=0D=0A	=0D=0A	Pub=
lic Constructor {=0D=0A	        Super();=0D=0A	        MutableSortDefinit=
ion sort =3D new MutableDefinition();=0D=0A	        Sort.setXXX(xxx);=0D=0A=
	        Sort.setYYY(yyy);      =0D=0A	        Sort.setZZZ(zzz);=0D=0A	  =
      sortDef =3D sort;=0D=0A	}=0D=0A	=0D=0A	Jean-Pierre=0D=0A	=0D=0A	=0D=
=0A	=0D=0A	=0D=0A	=0D=0A	------------------------------------------------=
-------=0D=0A	This sf.net email is sponsored by:ThinkGeek=0D=0A	Welcome t=
o geek heaven.=0D=0A	http://thinkgeek.com/sf=0D=0A	______________________=
_________________________=0D=0A	Springframework-developer mailing list=0D=
=0A	Spr...@li...=0D=0A	https://lists.s=
ourceforge.net/lists/listinfo/springframework-developer=0D=0A	=0D=0A=0D=0A=
=0A=0A********** L'ADSL A 20 EUR/MOIS********** =0AAvec Tiscali, l'ADSL e=
st =E0 20 EUR/mois. Vous pourrez chercher longtemps avant de trouver moin=
s cher ! =0APour profiter de cette offre exceptionnelle, cliquez ici : ht=
tp://register.tiscali.fr/adsl/=0AOffre soumise =E0 conditions.=0A

RE: [Springframework-developer] MutableSortDefinition

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

RmVlbCBmcmVlIHRvIHJlL2FkZCBpdCBpZiB5b3UgYWN0dWFsbHkgbmVlZCBpdCAtIEkgZml4ZWQg
YnVnIGluIHRoZSBzb3J0IGRlZmluaXRpb24gZGlydHkgZGV0ZWN0aW9uIHZpYSBhIGNvcHkgY29u
c3RydWN0b3IgaW5zdGVhZCBvZiByZWZsZWN0aW9uLWJhc2VkIHByb3BlcnR5IGNvcHlpbmcgKG9u
bHkgb2NjdXJlZCBvbiBjZXJ0YWluIEpES3MgbGlrZSBTdW4gMS4zLjEpLg0KIA0KSnVlcmdlbg0K
KHllcywgSSBhZG1pdCBpdCwgcmVhZGluZyBteSBlbWFpbHMgZnJvbSBhbiBJbnRlcm5ldCB0ZXJt
aW5hbCBpbiBBdXN0cmFsaWEgOy0pDQogDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSAN
CglGcm9tOiBKUCBQYXdsYWsgW21haWx0bzpqcC5wYXdsYWtAdGlzY2FsaS5mcl0gDQoJU2VudDog
U2F0IDgvMzAvMjAwMyAyOjQ0IFBNIA0KCVRvOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxp
c3RzLnNvdXJjZWZvcmdlLm5ldCANCglDYzogDQoJU3ViamVjdDogW1NwcmluZ2ZyYW1ld29yay1k
ZXZlbG9wZXJdIE11dGFibGVTb3J0RGVmaW5pdGlvbg0KCQ0KCQ0KDQoJSnVlcmdlbiwNCgkNCglJ
cyBpdCBhIHJlYXNvbiBmb3Igd2hpY2ggdGhlIE11dGFibGVTb3J0RGVmaW5pdGlvbiBoYXMgbm8g
bW9yZSBhDQoJY29uc3RydWN0b3Igd2l0aCBpdHMgcHJvcGVydGllcyAocHJvcGVydHksIGFzY2Vu
ZGluZywgaWdub3JlQ2FzZSBhbmQNCglldmVudHVhbGx5IHdoaWNoIHdhcyBub3Qgb24gdGhlIHBy
ZXZpb3VzIGNvbnN0cnVjdG9yDQoJdG9nZ2xlQXNjZW5kaW5nT25Qcm9wZXJ0eSk/DQoJSXQncyBu
b3cgaW5zdGVhZCBhIGNvbnN0cnVjdG9yIHRha2luZyBhIGJhc2Ugc29ydCBkZWZpbml0aW9uIHRo
YXQgZG9uJ3QNCgloZWxwIG1lLg0KCQ0KCUl0IHdhcyBzaW1wbGVyIHRvIGNyZWF0ZSBzb3J0IGRl
ZmluaXRpb25zLg0KCQ0KCVNvcnREZWZpbml0aW9uIHNvZXJ0RGVmID0gbmV3IE11dGFibGVTb3J0
RGVmKC4uLik7DQoJDQoJSGFzIG5vdyB0byBiZSByZXBsYWNlZCBieQ0KCQ0KCVNvcnREZWZpbml0
aW9uIHNvZXJ0RGVmOw0KCQ0KCVB1YmxpYyBDb25zdHJ1Y3RvciB7DQoJICAgICAgICBTdXBlcigp
Ow0KCSAgICAgICAgTXV0YWJsZVNvcnREZWZpbml0aW9uIHNvcnQgPSBuZXcgTXV0YWJsZURlZmlu
aXRpb24oKTsNCgkgICAgICAgIFNvcnQuc2V0WFhYKHh4eCk7DQoJICAgICAgICBTb3J0LnNldFlZ
WSh5eXkpOyAgICAgIA0KCSAgICAgICAgU29ydC5zZXRaWlooenp6KTsNCgkgICAgICAgIHNvcnRE
ZWYgPSBzb3J0Ow0KCX0NCgkNCglKZWFuLVBpZXJyZQ0KCQ0KCQ0KCQ0KCQ0KCQ0KCS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCglUaGlzIHNm
Lm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6VGhpbmtHZWVrDQoJV2VsY29tZSB0byBnZWVrIGhl
YXZlbi4NCglodHRwOi8vdGhpbmtnZWVrLmNvbS9zZg0KCV9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQoJU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWls
aW5nIGxpc3QNCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5l
dA0KCWh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3NwcmluZ2Zy
YW1ld29yay1kZXZlbG9wZXINCgkNCg0K