Menu
▾
▴
springframework-developer
|
From: <rod...@in...> - 2003-09-03 13:36:49
|
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 |
|
From: <rod...@in...> - 2003-09-03 15:17:56
|
>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 |
|
From: Colin S. <col...@ex...> - 2003-09-03 17:32:24
|
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... |
|
From: Kopylenko, D. <dko...@ac...> - 2003-09-03 21:53:36
|
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 |
|
From: Rod J. <rod...@in...> - 2003-09-03 21:57:44
|
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 |
|
From: Colin S. <col...@ex...> - 2003-09-03 22:35:26
|
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
|
|
From: Colin S. <col...@ex...> - 2003-09-04 16:34:15
|
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 |
|
From: Colin S. <col...@ex...> - 2003-09-04 21:10:58
|
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
|
|
From: Ivan R. <iv...@we...> - 2003-09-03 22:07:57
|
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 ] |
|
From: Ken K. <kk...@kk...> - 2003-09-03 13:45:05
|
+1 rod...@in... wrote: >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 > > > > |
|
From: Colin S. <col...@ex...> - 2003-09-03 14:05:17
|
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. What I think would be useful for Spring is a tool for verifying that all classes and interfaces which have been specified in a context definition are actually available on the classpath. I have been hit by typos a few times, and having a tool in the build which would verify the context in this respect would be useful... rod...@in... wrote: >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 > > |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-09-03 19:05:17
|
+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 |
|
From: Rod J. <rod...@in...> - 2003-09-03 23:47:41
|
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 |
