Spring support issues and wishes
So I've finally gotten the team on 7m1, which means I can finally use Spring facets on the day job. Overall, I'm pleased with the support, but there is still a ways to go for a full "develop with pleasure" experience. I'll submit JIRAs for all of these (or possibly a patch), but figured a batch discussion here on gaps would be valuable.
*It's very nice that you get a warning if you attempt to reference an unknown class, and that a quickfix exists to create that class if necessary. However, if the class is actually available in an inadvertantly not-depended-upon library or module, a quickfix should be available to add the missing dependency, as in Java.
*The reference resolver can't find import files if they are in another module, even if that module has a dependency. This isn't too bad of a problem if you put the imported files in a file list, except that it keeps Spring validation from working. An intention to add imported files to appropriate filesets would also be nice
*The "New Spring Config" action should have checkboxes for any of the standard namespaces (tx:, aop:, util:, etc.), so that I don't have to try to remember where they are. Support for automatically adding standard namespaces after file creation would also be handy
*The property type checker doesn't seem to understand generics. If the type of a property contains a type parameter, it complains, even if that type parameter is bound on the class of the bean.
*Value checking needs to understand the "${property.name}" syntax supported by the PreferencesPlaceholderConfigurer. All of our Spring files include constants externalized to property files, and such are flagged as errors if they are of any type other than String. For extra bonus points, navigation/completion/tooltips for properties file entries would be crucial.
*It should be possible for IDEA to automatically create wirings, for properties for which there is only one correctly-typed bean in scope (a very common occurence). This could either be on a per-property basis (picture an intention that says "Bind datasource property to oracleDataSource bean"), or in batch (an intention that just says "Wire up available properties"). I had this in my personal Spring plugin, and it ruled.
*If a property is annotated as @Required, but is missing, there should be an error flagged, with a quickfix if possible. Waiting till a runtime warning comes from RequiredAnnotationBeanPostProcessor is pointless.
*You need to support the p: pseudo-namespace from Spring 2.0. Here's the details: http://blog.interface21.com/main/2006/11/25/xml-syntax-sugar-in-spring-20/. A tool to automatically convert Spring XML files to use the p: format would win many extra bonus points
*It would be very handy if I could automatically take class declared as InitializingBean and automatically add 'init-method = "afterPropertiesSet"' to all beans of that class, and then remove the InitializingBean interface from the class. Same for DisposableBean. This supports the Spring folks suggestion that initialization/shutdown should be specifically declared in the configuration, and not implicitly declared via interface anymore.
*The gutter icon for navigating to Spring property bindings, should be a little leaf, not a "p" . (The functionality rules, BTW).
*Spring refactorings: Extract Parent Bean, Pull Properties Up, Push Properties Down, Conver Anonymous Bean to Named, Convert Named Bean to Anonymous, Split Configuration File, Move Bean to Configuration File
*The dependencies graph is cool, but the nodes are too large. Instead of showing properties and bindings in the node, simply label the edges corresponding to the property with the binding for the node
Overall, great work, and it just needs a bit of polishing to be as good as the rest of your product.
--Dave Griffith
Please sign in to leave a comment.
Hello Dave,
Very nice to know that you are now looking into this as well!
Dmitry/Sergey/Peter can now expect (even more) good bug reports/feature requests
flooding them :)
Good idea. I'll file another issue to add missing xsi:schemaLocation mapping.
Spring requires these at runtime (except for "beans" and "p" namespaces).
Both of these could also work for custom namespaces, since info can be retrieved
from "META-INF/spring.schemas".
In addition, there has been a "register namespace" quickfix for unresolved
qualified elements since Demetra.
Everything you name works as described, but for PropertiesPlaceholderConfigurer.
I assume you're writing some desktop application that uses Preferences API?
Anyway, please file a request, since I'm not familiar with PreferencesPlaceholderConfigurer
myself.
In addition I'll submit requests for:
-ServletContextPropertyPlaceholderConfigurer
-The new <context:property-placeholder/> element from spring 2.1
Bean reference completion is type aware, so I don't undestand what you're
referring to. An intention?
Are you talking about registering a class as a new bean in a context, and
have IDEA "autowire" (so to say) non-ambiguous reference dependencies?
Do you have ctor-args/required properties in mind, or just "optional" setter
dependencies?
Please describe in great detail :)
IDEADEV-14383
However, it's possible to configure RequiredAnnotationBeanPostProcessor to
recognize custom annotations - I'll submit a new one for that, since it's
a bit more obscure than basic @Required support.
IDEADEV-14263
Some thoughts:
-The "p:foo-ref" syntax is totally ugly (why didn't spring people choose
separate namespace for references?)
-The "p" namespace name is silly, should have been "property". There's no
coming world shortage in characters yet :)
-Convert/Migrate is a nice idea, my style preference would be to limit this
to simple numeric/boolean/String properties.
-Perhaps simple back-and-forth intention would be a good first step?
Good one.
Why? And why a little leaf.
Perhaps <lookup-method> could get similar support?
Btw, "Create Patch" should also be something else, not a "p".
See also IDEADEV-17228 for a request for bean gutter mark improvement..
Some of these are in JIRA already:
IDEADEV-13688
IDEADEV-13690
IDEADEV-13689
However, some are valuable while others may be frivolous.
Which ones are important for you, and why?
I don't think the property is that important. The dependency is important,
and apparent from the connection.
Anyway, imho graph is a nice extra but not important. However, some small
changes could both simplify and improve it. More details later.
I look forward to more discussion on the subject :)
Kind regards,
Taras
The biggest issue and wish for me would be to step out of the closet and support custom namespaces. That is one of the most important new features in Spring 2, and with the current level of support in the plugin it is just useless. E.g. check http://jetbrains.net/jira/browse/IDEA-13342
I hope the above mentioned support for resolving via spring.schemas will help push it in the right direction. Just a tip: spring.schemas can reference URIs as well as classpath resources, don't make us file another bug :))
+
Everything you name works as described, but for PropertiesPlaceholderConfigurer.
I assume you're writing some desktop application that uses Preferences API?+
Nope, I'm using some third-hand cut-and-paste config files, and I honestly couldn't say why it was using PreferencesPlaceholderConfigurer. Changing it to PropertiesPlaceholderConfigurer indeed results in everything working. I will file a report for the preferences version.
+
Bean reference completion is type aware, so I don't undestand what you're
referring to. An intention?
Are you talking about registering a class as a new bean in a context, and
have IDEA "autowire" (so to say) non-ambiguous reference dependencies?
Do you have ctor-args/required properties in mind, or just "optional" setter
dependencies?+
You create a bean, setting it's class (or factory, etc.). An intention is then available on the bean which says "Autowire properties". Any setters which can be unambiguously bound in the current context have their properties automatically added to the bean configuration. Constructor args are more difficult, since all of the args for a constructor have to be unambiguously bindable, but it's still doable. It's totally sweet to see a half-dozen property bindings added at a stroke, and the requirements for unambiguousness are very common. Basically, you get all of the ease-of-use of runtime auto-wiring with none of the scariness.
Agreement on all of the points wrt the p: namespace
And why a little leaf.
Leaf means Spring, and when I want to do the search what I'm thinking is "find this in Spring". Little circles mean either declarations, or pointers to declarations (if followed by an arrow). "P" means "property declaration", which isn't what I want at all.
On refactorings
+However, some are valuable while others may be frivolous.
Which ones are important for you, and why?+
I actually had all of them in my personal Spring plugin, and found them very valuable. "Extract Parent Bean" and "Pull Properties Up"/"Push Properties Down" probably had the biggest bang-for-the-buck, but that could have been due to my project structure (a bezillion DAO and Serializer classes, all extending from shared base classes). I'll submit JIRA for those.
--Dave Griffith
Hello Andrew,
Do you have some examples?
-tt
Sure: http://svn.mule.codehaus.org/browse/mule/branches/mule-2.x/core/src/main/resources/META-INF/spring.schemas?r=6756
The http://www.mulesource.org/schema/mule/core/2.0/mule.xsd is the namespace used in a Spring config file, which is mapped to a classpath resource META-INF/mule.xsd. There's no file deployed at the URI yet, so it's using classpath 100%.
HTH,
Andrew
Hello Andrew,
Andrew, do you have a link to an example instance document?
As far as I can see, it looks no different than the "standard" way to link
up schemas for namespace handlers in spring:
1) declare namespace in instance document (actual xml document)
2) declare xsi:schemaLocation URL for that namespace (also in instance document)
3) mapping inside "spring.schemas" that links schemaLocation URL to actual
classpath path for resource
(see also http://erik.jteam.nl/?p=27)
As far as I understand, mule works exactly this way. Correct?
In addition, do you have good knowledge of mule namespace handlers?
Regards,
-tt
Taras,
The schema is right next to this file at http://tinyurl.com/2tfwo4
If you mean an XML using the example, then you can use e.g. this simpler one: http://tinyurl.com/2h8oe9
Your assumptions for a schema resolution process are correct.
>> In addition, do you have good knowledge of mule namespace handlers?
What exactly do you mean? :) Mule's schema uses some more complex types, with validations, support for number substitution, etc. Not sure it caused a problem in IDEA so far, but that would be a good test, as Mule pushes Spring's namespace handlers to the limit (Ross submitted enhancements before, most of them incorporated in Spring).
Cheers,
Andrew
Hello Andrew,
1) Do the mule schemas use spring tooling annotations (for attributes)?
2) What do you think would be most valuable in terms of support IDEA could
provide?
For example, should IDEA recognize bean definitions coming from mule
handlers?
-tt
Taras,
Not sure I follow, I've pinged our schema jedi, he may provide more input :)
Well, I didn't dare to ask for it :) But it was on my list of TODO-things-one-always-wants-to-pursue-but-never-does-for-many-reasons. I already took a look at the plugin code (good its public), and don't see why it shouldn't be possible. If IDEA could provide templates for Mule constructs, that would be a killer application of all 3 technologies ;) I would even claim I'd be happier to have this, rather than some fancy drag-n-drop IDE which goes no further than being a nice toy.
Of course, the schemas are still live, and not all of them are available yet, but we are approaching a beta release for Mule 2.x next month.
Andrew
Hi,
Andrew P asked me to comment here because I've been involved in the development of Mule's use of schema. Unfortunately I wasn't there at the start (I've been mainly completing and tidying things).
We don't use Spring tooling annotations, as far as I know. In fact, I hadn't heard of them before and am having trouble googling much about them. Can you give me a pointer?
Also, I don't understand what you have in mind when you ask "should IDEA recognize bean definitions coming from mule handlers?". I guess you're saying that you can tie the schema to the Java classes we use, but I don't understand what you want to do with that. In general, I don't think that relationship is so important for the end user, but it would be nice for us (developers) if one could easily jump back and forth between Java and Schema.
I use IntelliJ Idea (although I'm no expert - I only switched recently and for years used emacs...) and the issues I've noticed while using it to edit XML schema like http://svn.mule.codehaus.org/browse/mule/branches/mule-2.x/modules/acegi/src/test/resources/encryption-test.xml?r=7143 are:
- correct parsing/verification when xsi:type is used (I hope that file is OK - it passes whatever parser we are using, although IDEA flags delegate-security-provider as incorrect).
- some way of simplifying the import of namespaces. I have no idea how this would work, but we have a whole slew of schema - until the correct schema is included in the xml "header" the appropriate options are not available.
- better tooltip documentation. We are including annotation elements in the schema, but they don't appear in the GUI (at least, I haven't noticed anything).
- some way (again, no idea how) or prompting when xsi:type might be used (ie when subtypes extend the current type). The use of xsi:type is not very "user-friendly" and anything that would make it more intuitive would be useful (I'm assuming you understand all this - I am happy to explain why we are using xsi:type and what it does, if necessary).
Don't know if any of that helps. Probably completely irrelevant: if there was one thing I'd like IntelliJ to improve, it's the amount of disk access IDEA does.
Cheers,
Andrew (email acooke at mulesource dotcom)
Hello Andrew,
>> 1) Do the mule schemas use spring tooling annotations (for
>> attributes)?
>>
Let's look at an example: the "tx" namespace from spring declares an attribute
"transaction-manager" on element <tx:annotation-driven/>.
The schema declaration for that attribute includes something similar to:
---
<xsd:annotation>
<xsd:appinfo>
<tool:annotation kind="ref">
<tool:expected-type type="org.springframework.transaction.PlatformTransactionManager"/>
</tool:annotation>
</xsd:appinfo>
</xsd:annotation>
---
Purpose should be clear: it's saying "hey, I expect a bean name reference
to a bean of type PlatformTransactionManager".
There's a similar annotation that applies to property values (aka "I expect
a string containing a FQN").
I'm not familiar with mule spring handlers, so I don't know if contains many
attributes where such annotations are present (or could be added).
By the way, on a purely XSD level, XML editor in recent IDEA builds works
properly with the schemas used by spring (afaik).
If mule schemas use more complicated constructs, you might want to test around
a bit. If there are problems (for example missing or wrong element suggestions),
filing them in Jetbrains JIRA sooner rather than later will increase the
chance for a fix.
>> 2) What do you think would be most valuable in terms
>> of support IDEA could
>> provide?
>> For example, should IDEA recognize bean
>> definitions coming from mule
>> andlers?
I think Mule-specific templates should be in Mule-specific plugin :)
If you want to add this but can't, I suggest to file a request for an extension
point.
I meant to ask: "what generic support do you think IDEA could offer for namespace
handlers (that would also benefit mule)?".
For example, is it common for regular beans to refer to beans that are defined
by mule namespace handlers?
-tt
Ah, thanks for the explanation.
That's cute, and we should add them where they will help. However I doubt we will use them that much because the approach we've taken is a bit different - most of our configuration is better thought of as a little language that configures the system. The beans themselves tend to be implicit - typically the Java code generates a bean according to the element and injects it directly into the bean builder for the parent element in the DOM. So it's more of a "DSL approach" than a direct "wiring together of beans".
Having said that, I am going to raise an issue to remind us to revise the schema and add these tips where necessary.
Cheers,
Andrew