springframework-developer — Spring Framework developers list

RE: [Springframework-developer] Newbie question, content-type-setting for views...

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

Yup, you're absolutely right, but somehow, the contenttype wasn't set
yet in the TilesView, slight error ;-).

Comitting that in a sec.

Alef


-----Oorspronkelijk bericht-----
Van: rod...@in... [mailto:rod...@in...] 
Verzonden: Friday, September 05, 2003 12:37 PM
Aan: al...@jt...
CC: spr...@li...
Onderwerp: Re: [Springframework-developer] Newbie question,
content-type-setting for views...


Isn't it in AbstractView?

Re: [Springframework-developer] Newbie question, content-type-setting for views...

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

Isn't it in AbstractView?

[Springframework-developer] Newbie question, content-type-setting for views...

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

Hmmm,

I kind of can't find the place where to set the content-types for views!
Does anybody have any idea where to do this? In the Excel view for
instance it's set in a hard-coded manner, but I assume for JstlView and
also TilesView we wouldn't want to set this hard-coded, do we???

Anybody?

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: RE : [Springframework-developer] Another BeanFactory feature

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

Well, I think this feature could be pretty useful... The only thing I
was thinking of is: how about multiply properties wiring
automatically... As I understand it right now, there's only one property
per bean that can be autowired...

Alef


-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
Jean-Pierre
Verzonden: Friday, September 05, 2003 12:17 AM
Aan: 'Rod Johnson'; 'Ivan Ristic'
CC: spr...@li...
Onderwerp: RE : [Springframework-developer] Another BeanFactory feature


+1

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

Jean-Pierre

-----Message d'origine-----
De=A0: spr...@li...
[mailto:spr...@li...] De la
part de Rod Johnson Envoy=E9=A0: jeudi 4 septembre 2003 23:42 =C0=A0: =
Ivan
Ristic Cc=A0: spr...@li...
Objet=A0: 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

[Springframework-developer] jdbc.object.StoredProcedure under construction

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

I have started to work on implementing a feature for returning resultsets from
the StoredProcedure class.  The first step is to convert StoredProcedure to use
JdbcTemplate so I can reuse some of the resultset extraction code.  Before doing
this, I moved the OutputParameter out of the StoredProcedure class to its own
file org.springframework.jdbc.core.SqlOutParameter.  So, anybody currently using
the StoredProcedure class will have to add this import and also change the name
for the OUT parameter declarations to SqlOutParameter.  This new name fits
better with the jdbc naming as in CallableStatement.registerOutParameter().

I have not committed anything yet, I just wanted to alert you that there are
some minor things that you will have to change if you use the StoredProcedure
class, and also give you a chance to voice any concerns regarding these changes.

I'll keep you posted.

Thomas

[Springframework-developer] Design question

[JP P. <jp....@ti...>]

Hi,

=20

I have a question about design.

=20

I have completely separated the web level from the business and
persistence ones. Even all beans related to the core
business-persistence are declared in applicationContext.xml.

The XXXservlet.xml contains only what is related to the UI and web
level.

I use on the business tier a facade that is the only expected interface
to use from the web level.

=20

I take care of this and all works fine. But the best would be to find a
way to:

- Continue to be able to test the classes in a test environment

- Deny access to web classes on the business ones except the fa=E7ade.

=20

As web controllers and others have or can have an application context,
they have the possibility of short cutting the fa=E7ade.

They can by example with getBean() find a configured and running DAO.

=20

It=92s only a matter of coerce to good practice. Using mainly beans and
interfaces makes this a bit harder.

=20

Has anyone an idea?

=20

Jean-Pierre

RE : [Springframework-developer] Another BeanFactory feature

[Jean-Pierre <jp...@jp...>]

+1

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

Jean-Pierre

-----Message d'origine-----
De=A0: spr...@li...
[mailto:spr...@li...] De la
part de Rod Johnson
Envoy=E9=A0: jeudi 4 septembre 2003 23:42
=C0=A0: Ivan Ristic
Cc=A0: spr...@li...
Objet=A0: 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

Re: [Springframework-developer] Another BeanFactory feature

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

>    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.

Re: [Springframework-developer] Another BeanFactory feature

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

Ivan Ristic wrote:

>
>> I've just prototyped another potential BeanFactory feature that 
>> tackles the
>> PicoContainer head on.
>>
>> I call it "autowire". Another new optional attribute on <bean>, 
>> although it
>> could be supported in non-XML factories as well.
>
> >
> > ...
> >
>
>> Is this worthwhile behaviour? Should I commit it (probably tomorrow)?
>>
>> Again I think the marketing value is the most important thing. This 
>> would
>> enable us to say that we can do anything PicoContainer does, and more.
>>
>> Whether I'd use it myself, I'm not sure. But it wouldn't bother me if I
>> didn't choose to use it.
>
>
>   I am giving my comments from a position of someone who has only
>   observed Spring from a (sometimes short) distance but hasn't used
>   in a project yet. Please feel free to disregard my comments if you
>   wish.
>
>   When I was trying out the Web MVC part of Spring I got confused
>   with the behavior of the SpringServlet (hope I got the name right),
>   where I didn't have to give it anything - it simply went to
>   the application context and got stuff out of it itself.
>   Things were happening somehow and it wasn't clear how. It took
>   me some time to figure out what was happening. Honestly, that
>   part of the framework is still a bit blurry to me.
>
>   On a similar note, I would prefer to have only one way to
>   configure beans. I understand how it may look interesting to
>   have beans wired automatically but I suspect people will then have
>   to put comments to explain to other people what's really going on.
>
>   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 think automagic behaviour is actually quite good when it covers almost all
cases actually. Typing a lot of the same stuff over and over is no good when
a framework can do it for you in 99% of the cases. I would really hate to
have to on a regular basis do work that a framework can do for me, just to
make things clearer on initial use.

On the basis of the above though, I certainly don't think the new stuff 
Rod is
describing qualifies for being on by default, since it wouldn't apply 
much of
the time. But I do think it's maybe worth being in there are an option, 
if even
for the marketing aspect. Like it or not, people have a number of choices in
what frameworks/containers they use; we think Spring is the best choice, but
sometimes people will not get past a pure feature comparison, so sometimes
you have to add some things just on this basis.

Regards,
Colin

Re: [Springframework-developer] Another BeanFactory feature

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

> I've just prototyped another potential BeanFactory feature that tackles the
> PicoContainer head on.
> 
> I call it "autowire". Another new optional attribute on <bean>, although it
> could be supported in non-XML factories as well.
 >
 > ...
 >
> Is this worthwhile behaviour? Should I commit it (probably tomorrow)?
> 
> Again I think the marketing value is the most important thing. This would
> enable us to say that we can do anything PicoContainer does, and more.
> 
> Whether I'd use it myself, I'm not sure. But it wouldn't bother me if I
> didn't choose to use it.

   I am giving my comments from a position of someone who has only
   observed Spring from a (sometimes short) distance but hasn't used
   in a project yet. Please feel free to disregard my comments if you
   wish.

   When I was trying out the Web MVC part of Spring I got confused
   with the behavior of the SpringServlet (hope I got the name right),
   where I didn't have to give it anything - it simply went to
   the application context and got stuff out of it itself.
   Things were happening somehow and it wasn't clear how. It took
   me some time to figure out what was happening. Honestly, that
   part of the framework is still a bit blurry to me.

   On a similar note, I would prefer to have only one way to
   configure beans. I understand how it may look interesting to
   have beans wired automatically but I suspect people will then have
   to put comments to explain to other people what's really going on.

   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.

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

[Springframework-developer] wrapping an interceptor and Hibernate specific TransactionProxyFactoryBean

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

I was using the TransactionProxyFactoryBean with the 
HibernateTransactionManager, but when I switched to the 
JTATransactionManager, got bitten by the fact that I no longer had 
anything creating a Hibernate session and binding it to the current 
thread, as HibernateTransactionManager used to do by default.

One verbose solution would have been to have gone back to the old 
ProxyFactoryBean mechanism for handling transactions, and just stack a 
HibernateInterceptor in front of the transaction interceptor.

I decided instead to make a Hibernate specific verison of 
TransactionProxyFactoryBean. All it does is take a new 
HibernateInterceptor property, and in afterPropertiesSet add the 
interceptor before the transaction one (however, unlike the transaction 
one, it will execute on all invocations, since you may want to run some 
methods with a hibernate session, but no transactions.
        // allways invoke the Hibernate Interceptor
        addInterceptor(hibernateInterceptor);
        ... existing code to set up the Transaction interceptor

Now my questions:
1: is it worth checking something like this in? I made a cut and past 
copy of TransactionProxyFactoryBean, and added the new property and 
modified the afterPropertiesSet. Obviously, I could also have just 
subclasses the existing class and overriden afterPropertiesSet. That's 
probably a better choice, but maybe a bit more dangerous if something 
changes in the parent method which is no longer called at all.
2: is there a better way of doing this? I supposed I could have wrapped 
the proxy in another proxy to add the hibernate interceptor. This would 
not have required any code changes, but would have made for a lot more 
typing in the context.  Another option would be to add optional before 
and after, 'always invoke' interceptor properties to the 
TransactionProxyFactoryBean, so something like this can be added.

Regards,
Colin

[Springframework-developer] Another BeanFactory feature

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

All,

I've just prototyped another potential BeanFactory feature that tackles the
PicoContainer head on.

I call it "autowire". Another new optional attribute on <bean>, although it
could be supported in non-XML factories as well.

Again it's backward compatible. It doesn't complicate the API, although it
obviously adds a bit more code to the implementation.

I see it working in 3 modes:

- autowire="none": the traditional and default behaviour. Dependency
checking might be used here if desired.

- autowire="byType": if a bean exposes a property of type Foo and there's
exactly one bean of type Foo defined in the same factory, the property of
type Foo is set to the other bean automatically. My prototype does nothing
if there are 0 or >1 beans of type Foo; not sure if this should result in an
exception. This is basically PicoContainer behaviour: good for small
factories with one object of each type but inadequate for more complex
scenarios, which Spring already supports well.

- autowire="byName": if a bean exposes a property with name "spouse" it's
automatically set to the value of the "spouse" bean in the same factory if
one is present. If this results in a type mismatch that's a fatal error.
This behaviour has no parallel in PicoContainer but might be useful in some
cases. It would work even if there were multiple beans of the type of
Spouse.

Implementation wasn't very complex.

Is this worthwhile behaviour? Should I commit it (probably tomorrow)?

Again I think the marketing value is the most important thing. This would
enable us to say that we can do anything PicoContainer does, and more.

Whether I'd use it myself, I'm not sure. But it wouldn't bother me if I
didn't choose to use it.

Regards,
Rod

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

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

Currently XmlWebApplicationContext builds up a defualt path for the 
application context as
  /WEB-INF/applicationContext.xml

then, in AbstractApplicationContext, this is attempted to be loaded via 
a regular getResourceAsStream call, which fails (as you'd expect it to), 
then does successfully get loaded via the
   new FileInputStream(path)
call in getResourceByPath().

However, if you look in the Servlet spec, nowhere does it say that the 
base directory for file operations has to be set to the base directory 
of the webapp. This certainly does work in JBoss and TomCat, the two 
environments where I've tried Spring, but I think the much better 
behaviour would be to rely on the
  getResourceAsStream()
method in ServletContext, which according to the spec _is_ guaranteed to 
include the web-app base in the classpath searched by that call.

One way to handle this would be to implement/override 
getResourceAsStream in XmlWebApplicationContext, instead of relying on 
the one in the abstract base class.

Regards,

Colin

RE: [Springframework-developer] TransactionInterceptor setup in t he webapp-aop skeleton file is bad

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

Colin,

I'll update it in the CVS.

Regards,
Dmitriy.

-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...] 
Sent: Wednesday, September 03, 2003 6:35 PM
To: 'springframework-developer '
Cc: ben...@ac...
Subject: [Springframework-developer] TransactionInterceptor setup in the
webapp-aop skeleton file is bad


In the file
  samples/skeletons/webapp-aop/WEB-INF/applicationContext.xml
there is an example of how to set up a transaction interceptor. It is 
using the old mechanism, which is not the problem, but is wrong, which 
is the problem.

The example uses
    <bean id="exampleTransactionInterceptor" 
class="org.springframework.transaction.interceptor.TransactionInterceptor">
        <property name="transactionManager"><ref 
bean="myTransactionManager"/></property>
        <property name="transactionAttributeSource">
            <value>
                
example.ExampleBusinessObject.exampleMethod=PROPAGATION_REQUIRED
                
example.ExampleBusinessObject.anotherExampleMethod=PROPAGATION_REQUIRED
            </value>
        </property>
    </bean>
    <bean id="exampleBusinessObject" 
class="org.springframework.aop.framework.ProxyFactoryBean">
        <property 
name="proxyInterfaces"><value>example.ExampleBusinessInterface</value></prop
erty>
        <property 
name="interceptorNames"><value>exampleTransactionInterceptor,exampleBusiness
ObjectTarget</value></property>
    </bean>

Now this is specifyng that ExampleBusinessObject.exmpleMethod and 
ExampleBuisnessObject.anotherExampleMethod should be intercepted and 
handled transactionally, but if the user comes in via the interface 
ExampleBusinessInterface like he should be, then the interceptor will 
not match up on the method names, since the class he is coming in as is 
ExampleBusinessInterface not the ExampleBusinessObject the interceptor 
is looking for.

This is the exact problem that Ben Alex was having last week (but I 
didn't spot it at the time). Hopefully he didn't give up on spring yet :-)

Can somebody fix this?  Also, fwiw this doesn't happen with the new, 
streamlined mechanism, TransactionProxyFactoryBean, since there you 
directly point to the object you are proxying, and match the method 
coming in regardless.

Also, it's probably worth updating the example to show both the old 
mechanism and the new one.

Regards,
Colin








-------------------------------------------------------
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] Dependency checking

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

I've committed dependency check support to CVS.

I think it's useful to avoid the need to write code to check that a certain
field is non-null. I've done this once or twice in init methods. Of course
where there are defaults it fails.

I guess I could have added a check that the field wasn't null...Maybe that
would be a good modification? That would work with default values.

Thomas, I've updated the DTD. Can you please put the latest version on the
web site? I've also constrained the legal values of the "singleton"
attribute to "true" or "false".

Regards,
Rod

----- Original Message -----
From: "Alef Arendsen (JTeam)" <al...@jt...>
To: <rod...@in...>; "'springframework-developer'"
<spr...@li...>
Cc: "'springframework-developer'"
<spr...@li...>
Sent: Wednesday, September 03, 2003 8:17 PM
Subject: RE: [Springframework-developer] Dependency checking


> +1
>
> I think this could be pretty useful (especially for colaborators), and I
> definitely see the marketing value...
>
> Alef
>
> -----Oorspronkelijk bericht-----
> Van: spr...@li...
> [mailto:spr...@li...] Namens
> rod...@in...
> Verzonden: Wednesday, September 03, 2003 3:37 PM
> Aan: springframework-developer
> CC: springframework-developer
> Onderwerp: Re: [Springframework-developer] Dependency checking
>
>
> All,
>
> As I can see it the only arguable advantage that
> PicoContainer has over Spring is that it can satisfy all
> dependencies before allowing an object to be invoked, so that
> an object can never be used when incompletely configured. I
> don't like their constructor way of doing this, and I think
> that it often makes sense to have optional properties, with
> sensible default. So I've never been worried by this in
> Spring.
>
> However, it's pretty easy to add optional dependency
> checking. I've successfully prototyped the following, which
> required very minor changes:
> - add a new DTD attribute for the "bean" element called
> dependencyCheck
> - if this is set to true, XmlBeanFactory checks that all
> properties on that bean have been set. If not it throws an
> UnsatisfiedDependencyException. We can't do the PicoContainer- style
> automatic wiring up as we can support multiple objects
> of any type. They can only accomplish this because they
> support only a single object of each type, which doesn't
> satisfy the kind of real-world requirements I've used Spring
> in.
>
> At present my prototype checks only Object properties
> (presumably other beans in the factory). It might be good to
> have three values for dependencyCheck: "no"
> (default), "object" (collaborators) and "all" (primitives and
> collaborators).
>
> As this is backward compatible and easy to do I'm inclined to
> add it, if only for marketing value. There may be real value
> in that it means that an init method wouldn't need to check
> that a certain property was non-null.
>
> What do you think? Is this worthwhile?
>
> 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
>
>
>
> -------------------------------------------------------
> 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] TransactionInterceptor setup in the webapp-aop skeleton file is bad

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

In the file
  samples/skeletons/webapp-aop/WEB-INF/applicationContext.xml
there is an example of how to set up a transaction interceptor. It is 
using the old mechanism, which is not the problem, but is wrong, which 
is the problem.

The example uses
    <bean id="exampleTransactionInterceptor" 
class="org.springframework.transaction.interceptor.TransactionInterceptor">
        <property name="transactionManager"><ref 
bean="myTransactionManager"/></property>
        <property name="transactionAttributeSource">
            <value>
                
example.ExampleBusinessObject.exampleMethod=PROPAGATION_REQUIRED
                
example.ExampleBusinessObject.anotherExampleMethod=PROPAGATION_REQUIRED
            </value>
        </property>
    </bean>
    <bean id="exampleBusinessObject" 
class="org.springframework.aop.framework.ProxyFactoryBean">
        <property 
name="proxyInterfaces"><value>example.ExampleBusinessInterface</value></property>
        <property 
name="interceptorNames"><value>exampleTransactionInterceptor,exampleBusinessObjectTarget</value></property>
    </bean>

Now this is specifyng that ExampleBusinessObject.exmpleMethod and 
ExampleBuisnessObject.anotherExampleMethod should be intercepted and 
handled transactionally, but if the user comes in via the interface 
ExampleBusinessInterface like he should be, then the interceptor will 
not match up on the method names, since the class he is coming in as is 
ExampleBusinessInterface not the ExampleBusinessObject the interceptor 
is looking for.

This is the exact problem that Ben Alex was having last week (but I 
didn't spot it at the time). Hopefully he didn't give up on spring yet :-)

Can somebody fix this?  Also, fwiw this doesn't happen with the new, 
streamlined mechanism, TransactionProxyFactoryBean, since there you 
directly point to the object you are proxying, and match the method 
coming in regardless.

Also, it's probably worth updating the example to show both the old 
mechanism and the new one.

Regards,
Colin

Re: [Springframework-developer] Dependency checking

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

Kopylenko, Dmitry wrote:
> How about JMX support for the bean factory, so the bean factory MBean
> component could be integrated with any JMX enabled container and could be
> managed easily by JMX container's provided tools (JMX adaptors) ?

   You may remember that I mentioned JMX some time ago. Well, I am
   patiently waiting for a 1.0 release so that we can discuss JMX
   (and a couple of other features) after that :)

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

Re: [Springframework-developer] Dependency checking

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

I thought Colin was talking about design time, not runtime. But JMX is also
potentially valuable. It would be great if it enabled us to address
application monitoring. This is an area in which EJB is currently quite
strong (decent containers like WebLogic etc.)

Regards,
Rod

----- Original Message -----
From: "Kopylenko, Dmitry" <dko...@su...>
To: <rod...@in...>; "'Colin Sampaleanu '" <col...@ex...>
Cc: "'springframework-developer '"
<spr...@li...>
Sent: Wednesday, September 03, 2003 10:53 PM
Subject: RE: [Springframework-developer] Dependency checking


> How about JMX support for the bean factory, so the bean factory MBean
> component could be integrated with any JMX enabled container and could be
> managed easily by JMX container's provided tools (JMX adaptors) ?
>
> Just an idea :-)
>
> Dmitriy.
>
> -----Original Message-----
> From: rod...@in...
> To: Colin Sampaleanu
> Cc: springframework-developer
> Sent: 9/3/2003 11:16 AM
> Subject: Re: [Springframework-developer] Dependency checking
>
> >Sounds sort of useful, although unless I am misunderstanding
> how this
> would work, it would not be useful for a lot of beans since
> you can use
> a lot of beans without setting all properties, relying on
> defaults, etc.
>
> Exactly, which is why I intend to leave the default as is.
> PicoContainer's approach seems to ignore the value of
> defaults (although they have just added support for multiple
> constructors, which may permit them).
>
> A tool would be great. I suffer from occasional typo trouble
> too. Apparently IDEA users don't when they refactor because
> it's smart enough to offer to update XML in the project as
> well.
>
> I would love to see tool support for Spring. Such as
> - Eclipse plugin
> - Swing GUI editor
> - XSLT that can generate nice documentation from an XML bean
> definition file
> - any other good suggestions?
>
> This should be a priority after 1.0, even if we lack
> bandwidth before then.
>
> 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

RE: [Springframework-developer] Dependency checking

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

How about JMX support for the bean factory, so the bean factory MBean
component could be integrated with any JMX enabled container and could be
managed easily by JMX container's provided tools (JMX adaptors) ?

Just an idea :-)

Dmitriy.

-----Original Message-----
From: rod...@in...
To: Colin Sampaleanu
Cc: springframework-developer
Sent: 9/3/2003 11:16 AM
Subject: Re: [Springframework-developer] Dependency checking

>Sounds sort of useful, although unless I am misunderstanding 
how this 
would work, it would not be useful for a lot of beans since 
you can use 
a lot of beans without setting all properties, relying on 
defaults, etc.

Exactly, which is why I intend to leave the default as is. 
PicoContainer's approach seems to ignore the value of 
defaults (although they have just added support for multiple 
constructors, which may permit them).

A tool would be great. I suffer from occasional typo trouble 
too. Apparently IDEA users don't when they refactor because 
it's smart enough to offer to update XML in the project as 
well.

I would love to see tool support for Spring. Such as 
- Eclipse plugin
- Swing GUI editor
- XSLT that can generate nice documentation from an XML bean 
definition file
- any other good suggestions?

This should be a priority after 1.0, even if we lack 
bandwidth before then.

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

RE: [Springframework-developer] Binding to a Collection

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

Any luck yet? I'm curious
 
alef
 

-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
Kopylenko, Dmitry
Verzonden: Wednesday, September 03, 2003 3:32 PM
Aan: 'spr...@li...'
Onderwerp: FW: [Springframework-developer] Binding to a Collection


To the list...
 
-----Original Message-----
From: Alef Arendsen (JTeam) [mailto:al...@jt...] 
Sent: Wednesday, September 03, 2003 9:28 AM
To: 'Kopylenko, Dmitry'
Subject: RE: [Springframework-developer] Binding to a Collection


There was a message on the forum a long time ago
(http://sourceforge.net/forum/message.php?msg_id=1997848) where someone
was asking the same thing.
 
Anybody, please correct me if I'm wrong, but I don't believe this is
possible using the current ServletRequestDataBinder and
BaseCommandController.
 
To support lists in combination with PropertyEditors, I once used a
ListDataBinder (extending ServletRequestDataBinder). With this
databinder it is possible to iterate over the objects in the list and
rendering fields/properties using the propertyeditors that are
registered... Quite straightforward. However, this only does the
rendering of properties using propertyeditors. How to do binding, I
don't know (yet). I'll attach the source of the ListDataBinder, which is
to instantiated in a AbstractListController. The fetchList-method in the
ListController class, atcually fetches the list (which is used in the
ListDataBinder)...
 
Example of usage:
<!-- the iterator from the ListDataBinder exposes the command object -->
<c:forEach items="binder-command-attribute-whatever" item="bla">
    <!-- the bind tag binds editors and values and stuff for the current
element in the collection -->
    <spring:bind path="propertyToRender">
        <:out value="${status.value}"/>
    </spring:bind>
</c:forEach>
 
have to go... I'll get back to you later...
 
cheers,
 
Alef
-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
Kopylenko, Dmitry
Verzonden: Wednesday, September 03, 2003 2:37 PM
Aan: 'spr...@li...'
Onderwerp: [Springframework-developer] Binding to a Collection



Hi everybody. I have one question, if any one has a quick answer :-)
What would be the best way to "bind" html data into a collection of
objects? 

Let's say I have an html table in the form, each row representing a
model/command object. When submitting this form to a Controller, I would
like to bind the values from the html table into a Collection of
model/command objects. What would be the best way to do that?

Thanks, 
Dmitriy. 

P.S. 

I believe there was a message about this issue on the list, but I'm to
lazy to search for it ;-) 

RE: [Springframework-developer] Dependency checking

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

+1

I think this could be pretty useful (especially for colaborators), and I
definitely see the marketing value...

Alef

-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
rod...@in...
Verzonden: Wednesday, September 03, 2003 3:37 PM
Aan: springframework-developer
CC: springframework-developer
Onderwerp: Re: [Springframework-developer] Dependency checking


All,

As I can see it the only arguable advantage that 
PicoContainer has over Spring is that it can satisfy all 
dependencies before allowing an object to be invoked, so that 
an object can never be used when incompletely configured. I 
don't like their constructor way of doing this, and I think 
that it often makes sense to have optional properties, with 
sensible default. So I've never been worried by this in 
Spring.

However, it's pretty easy to add optional dependency 
checking. I've successfully prototyped the following, which 
required very minor changes:
- add a new DTD attribute for the "bean" element called 
dependencyCheck
- if this is set to true, XmlBeanFactory checks that all 
properties on that bean have been set. If not it throws an 
UnsatisfiedDependencyException. We can't do the PicoContainer- style
automatic wiring up as we can support multiple objects 
of any type. They can only accomplish this because they 
support only a single object of each type, which doesn't 
satisfy the kind of real-world requirements I've used Spring 
in.

At present my prototype checks only Object properties 
(presumably other beans in the factory). It might be good to 
have three values for dependencyCheck: "no" 
(default), "object" (collaborators) and "all" (primitives and 
collaborators).

As this is backward compatible and easy to do I'm inclined to 
add it, if only for marketing value. There may be real value 
in that it means that an init method wouldn't need to check 
that a certain property was non-null.

What do you think? Is this worthwhile?

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

Re: [Springframework-developer] Dependency checking

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

rod...@in... wrote:

>>Sounds sort of useful, although unless I am misunderstanding 
>>    
>>
>how this 
>would work, it would not be useful for a lot of beans since 
>you can use 
>a lot of beans without setting all properties, relying on 
>defaults, etc.
>
>Exactly, which is why I intend to leave the default as is. 
>PicoContainer's approach seems to ignore the value of 
>defaults (although they have just added support for multiple 
>constructors, which may permit them).
>
>A tool would be great. I suffer from occasional typo trouble 
>too. Apparently IDEA users don't when they refactor because 
>it's smart enough to offer to update XML in the project as 
>well.
>  
>
For the record Eclipse also will change names in text and other files if 
you tell it to, so refactoring is not normally the issue for me. I am 
somewhat of a sloppy typist though, and do sometimes make errors on the 
initial input, those errors being caught only when I actually try to run 
the stuff.

>I would love to see tool support for Spring. Such as 
>- Eclipse plugin
>- Swing GUI editor
>- XSLT that can generate nice documentation from an XML bean 
>definition file
>- any other good suggestions?
>  
>
Although a full plugin that validates the whole file would be useful, 
now that I think of it, what is needed as a first easy step (in Eclipse, 
and every IDE) and would be very useful for Spring and any other kind of 
reflexive java programming is a fast one keycombo function to check the 
string constant you are in for validity as a java class or interface 
name. I will post an Eclipse feature request for this... This would be 
of help in using so many projects/libs...

Re: [Springframework-developer] Dependency checking

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

>Sounds sort of useful, although unless I am misunderstanding 
how this 
would work, it would not be useful for a lot of beans since 
you can use 
a lot of beans without setting all properties, relying on 
defaults, etc.

Exactly, which is why I intend to leave the default as is. 
PicoContainer's approach seems to ignore the value of 
defaults (although they have just added support for multiple 
constructors, which may permit them).

A tool would be great. I suffer from occasional typo trouble 
too. Apparently IDEA users don't when they refactor because 
it's smart enough to offer to update XML in the project as 
well.

I would love to see tool support for Spring. Such as 
- Eclipse plugin
- Swing GUI editor
- XSLT that can generate nice documentation from an XML bean 
definition file
- any other good suggestions?

This should be a priority after 1.0, even if we lack 
bandwidth before then.

Regards,
Rod

Re: [Springframework-developer] Javadocs

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

Rod,

> > Would be great to add 
> > some deprecation message to all of them, but that might be a 
> > pain.
> > 
> 
> We would have to change each page - I'll see what I can come up with.
> 
> What would you want the message to say?
> 

I'm imatient :-) -- with some help for our resident Perl guru, we added a
deprecation message to the navigation bar of all i21 javadocs.

Thomas

Re: [Springframework-developer] Javadocs

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

Rod,

> We still have com.interface21 Javadocs on the web site. (I've 
> only noticed after linking to the DataAccessException Javadoc 
> directly on a TSS thread :-( Can you please update them. 

they are updated now.

> Maybe leave the I21 docs as well!?? 

they are still there - changed the path and the link

> Would be great to add 
> some deprecation message to all of them, but that might be a 
> pain.
> 

We would have to change each page - I'll see what I can come up with.

What would you want the message to say?


Thomas