Menu
▾
▴
[Springframework-developer] Re: Springframework-developer digest, Vol 1 #2048 - 11 msgs
|
From: Ramin F. <aqu...@ya...> - 2006-01-19 07:09:29
|
Dear Alef Arendsen,
Here is what I find useful as a good IDEA Spring Integration. I am using Idea Spring plugin now and I find it very good but
I wish I could refactor spring beans when I was refactoring my code. Please take a look at this bean:
<bean id="loginForm" class="com.x.y.ac.web.LoginForm" singleton="false">
<property name="commandName">
<value>user</value>
</property>
<property name="validator">
<ref bean="userLoginValidator"/>
</property>
<property name="formView">
<value>home</value>
</property>
<property name="successView">
<value>board.htm</value>
</property>
<property name="userObject">
<ref bean="user"/>
</property>
<property name="userService">
<ref bean="userService"/>
</property>
</bean>
When I am changing the attributes of the LoginForm class, I wish there could be a mechanism that would alert me when I wanted to declare the attributes. Or automagically the plugin could generate the class with the exact attributes along with javadocs on setter methods indicating that these methods are used by Spring (Be aware that they are declared in application context xml files)
When I am coding in one of my controllers, I wish I could have a tooltip showing me getSuccessView() and other attributes in lieu of switching between code and application context files to see what is going on in there.
I am coding in a jsp file. I wish there was a mechanism that could give me a vision of the mapping related to the jsp.
<bean id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
...
<property name="mappings">
<props>
<prop key="/home.htm">loginForm</prop>
<prop key="/board.htm">boardController</prop>
<prop key="/ab_home.htm">abController</prop>
...
</props>
...
</property>
</bean>
There is a feature in the Spring Idea plugin now that doesn't sound delicate to me. I choose a set of files as my applicationContext xml files and when the Spring Idea panel has the focus, I can search a bean in the set context files. Its type ahead mechanism opens all application context files when I am typing the name of a bean. Unfortunately the name of a model, dao, service (in case of Spring MVC) and controller class is close to each other. So I have all context files opened in Intellij Idea and I find it annoying.
Alef when I thought about the features, I wasn't thinking about feasibility, I just thought how could I be more productive?
All The Best,
Ramin Farhanian
spr...@li... wrote:
Send Springframework-developer mailing list submissions to
spr...@li...
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/springframework-developer
or, via email, send a message with subject or body 'help' to
spr...@li...
You can reach the person managing the list at
spr...@li...
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Springframework-developer digest..."
Today's Topics:
1. Assumption about stack trace format and cacao (Olivier Jolly)
2. Re: Assumption about stack trace format and cacao (Juergen Hoeller)
3. Re: Assumption about stack trace
format and cacao (Olivier Jolly)
4. Re: Assumption about stack trace format and cacao (Juergen Hoeller)
5. RE: IDEA integration features (James Cook)
6. Re: IDEA integration features (Alef Arendsen)
7. Re: Assumption about stack trace format and cacao (Juergen Hoeller)
8. Re: Assumption about stack trace
format and cacao (Olivier Jolly)
9. spring build.398 Build Successful (al...@in...)
--__--__--
Message: 1
Date: Tue, 17 Jan 2006 10:16:44 +0100 (CET)
From: "Olivier Jolly"
To: spr...@li...
Subject: [Springframework-developer] Assumption about stack trace format and cacao
Reply-To: spr...@li...
Hi,
I'm using spring+GNU classpath right now to ensure that the free java
implementations can get the best framework around running neatly and when
underdoing the Jdk13ControlFlowTests, I noticed that the checks involving
methods were not working.
After a bit of investigations, I found that the stack trace generated by
cacao was putting an extra space between the end of the method name and
the parenthesis to precise the location. Since for 1.3 spec level the
search is done within the string image of the stack trace, the exact
formatting is very important and breaks in this case.
I was wondering who was "wrong" there and it seems that the sun javadocs
state that the format used by their jdk (and described in the docs) is
only an example (pasted from the Throwable javadoc : "The format of this
information depends on the implementation, but the following example may
be regarded as typical: [...]") so I don't think cacao can be thought as
non compliant with the spec. On the other hand, I do understand that if
the spec doesn't give details about the format, we either have to make
assumptions or forget it totally (but we don't have any other way to get
the stack trace in jvm1.4- afaik).
So basically I was wondering whether spring had to be aware of this quirk
(either by using a cacao compliant regexp when looking for methods, using
probably [ ]? or by "flagging" the test as runnable only in certain jvm
implementations) or if cacao had to be adapted.
Thanks for your feedback
Olivier
--__--__--
Message: 2
From: "Juergen Hoeller"
To:
Subject: Re: [Springframework-developer] Assumption about stack trace format and cacao
Date: Tue, 17 Jan 2006 10:27:09 +0100
Reply-To: spr...@li...
Interesting issue. So for a simple fix, would this mean that we should also
check for:
this.stackTrace.indexOf(clazz.getName() + "." + methodName + " (") != -1
With an extra space before the parenthesis?
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Olivier Jolly
Sent: Tuesday, January 17, 2006 10:17 AM
To: spr...@li...
Subject: [Springframework-developer] Assumption about stack trace format and
cacao
Hi,
I'm using spring+GNU classpath right now to ensure that the free java
implementations can get the best framework around running neatly and when
underdoing the Jdk13ControlFlowTests, I noticed that the checks involving
methods were not working.
After a bit of investigations, I found that the stack trace generated by
cacao was putting an extra space between the end of the method name and the
parenthesis to precise the location. Since for 1.3 spec level the search is
done within the string image of the stack trace, the exact formatting is
very important and breaks in this case.
I was wondering who was "wrong" there and it seems that the sun javadocs
state that the format used by their jdk (and described in the docs) is only
an example (pasted from the Throwable javadoc : "The format of this
information depends on the implementation, but the following example may be
regarded as typical: [...]") so I don't think cacao can be thought as non
compliant with the spec. On the other hand, I do understand that if the spec
doesn't give details about the format, we either have to make assumptions or
forget it totally (but we don't have any other way to get the stack trace in
jvm1.4- afaik).
So basically I was wondering whether spring had to be aware of this quirk
(either by using a cacao compliant regexp when looking for methods, using
probably [ ]? or by "flagging" the test as runnable only in certain jvm
implementations) or if cacao had to be adapted.
Thanks for your feedback
Olivier
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
--__--__--
Message: 3
Date: Tue, 17 Jan 2006 10:38:51 +0100 (CET)
Subject: Re: [Springframework-developer] Assumption about stack trace
format and cacao
From: "Olivier Jolly"
To: spr...@li...
Reply-To: spr...@li...
> Interesting issue. So for a simple fix, would this mean that we should
> also
> check for:
>
> this.stackTrace.indexOf(clazz.getName() + "." + methodName + " (") != -1
>
> With an extra space before the parenthesis?
Yes, exactly, that should do the trick nicely. I can confirm this later
when I'm home.
But, for performance issues, shouldn't it be better know which exact
pattern we're looking for ? If I understand right, the jdk13 way of doing
is already quite slow, it may hurt to make the situation worse ..
> Juergen
Olivier
--__--__--
Message: 4
From: "Juergen Hoeller"
To:
Subject: Re: [Springframework-developer] Assumption about stack trace format and cacao
Date: Tue, 17 Jan 2006 13:00:41 +0100
Reply-To: spr...@li...
I've just refined Jdk13ControlFactory to take this into account.
This should still be pretty efficient, since it does indexOf with start
indexes now, iterating over the stacktrace to find a match without
subsequent parenthesis - then checking the character right after the method
name whether it's a parenthesis or whitespace, either returning "found" or
increasing the index accordingly for the next iteration.
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Olivier Jolly
Sent: Tuesday, January 17, 2006 10:39 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Assumption about stack trace format
and cacao
> Interesting issue. So for a simple fix, would this mean that we should
> also check for:
>
> this.stackTrace.indexOf(clazz.getName() + "." + methodName + " (")
> != -1
>
> With an extra space before the parenthesis?
Yes, exactly, that should do the trick nicely. I can confirm this later when
I'm home.
But, for performance issues, shouldn't it be better know which exact pattern
we're looking for ? If I understand right, the jdk13 way of doing is already
quite slow, it may hurt to make the situation worse ..
> Juergen
Olivier
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
--__--__--
Message: 5
From: "James Cook"
To:
Subject: RE: [Springframework-developer] IDEA integration features
Date: Tue, 17 Jan 2006 09:25:44 -0500
Reply-To: spr...@li...
FWIW, IDEA also notices multiple ID's with the same name. At least in =
the
same file.
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of Mark Derricutt
> Sent: Monday, January 16, 2006 4:12 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] IDEA integration features
>=20
> *delurking for a bit*
>=20
> Have you noticed that IDEA already includes some spring integration?
> When adding a bean entry in your XML - IDEA will autocomplete any
>
elements for the defined bean class.
>=20
> I'm sure theres some more things under the covers that IDEAs doing as
> well, but would be great seeing some additional support.
>=20
> Theres also an existing spring plugin which provides visualisation of
> the beans (I think - I've not tried it out)..
>=20
> Mark
>=20
> On 1/17/06, Alef Arendsen wrote:
>=20
> > I'm currently investigating what kind of features we'd like to have =
in
> > IDEA when it comes to integration with Spring.
> >
> > I've got the following on the list so far and I'd really like your
> > input. So if you have any ideas about what kind of features IDEA =
could
> > offer that will help you develop your Spring application, I'd really
> > like to hear them!
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD =
SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
--__--__--
Message: 6
Date: Tue, 17 Jan 2006 16:26:44 +0100
From: Alef Arendsen
Organization: Interface21 B.V.
To: spr...@li...
Subject: Re: [Springframework-developer] IDEA integration features
Reply-To: spr...@li...
Yes, this should just be the XML validation, since the bean identifier
is an XML ID attribute.
regards,
Alef
James Cook wrote:
> FWIW, IDEA also notices multiple ID's with the same name. At least in the
> same file.
>
>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On Behalf
>> Of Mark Derricutt
>> Sent: Monday, January 16, 2006 4:12 PM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] IDEA integration features
>>
>> *delurking for a bit*
>>
>> Have you noticed that IDEA already includes some spring integration?
>> When adding a bean entry in your XML - IDEA will autocomplete any
>>
elements for the defined bean class.
>>
>> I'm sure theres some more things under the covers that IDEAs doing as
>> well, but would be great seeing some additional support.
>>
>> Theres also an existing spring plugin which provides visualisation of
>> the beans (I think - I've not tried it out)..
>>
>> Mark
>>
>> On 1/17/06, Alef Arendsen wrote:
>>
>>
>>> I'm currently investigating what kind of features we'd like to have in
>>> IDEA when it comes to integration with Spring.
>>>
>>> I've got the following on the list so far and I'd really like your
>>> input. So if you have any ideas about what kind of features IDEA could
>>> offer that will help you develop your Spring application, I'd really
>>> like to hear them!
>>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>> files
>> for problems? Stop! Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>> http://ads.osdn.com/?ad_idv37&alloc_id865&op=ick
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd_______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
--
Alef Arendsen
Interface21 NL
Spring Services from the Source
http://www.interface21.com
Spring Core Developer
http://www.springframework.org
Author, "Professional Java Development with the Spring Framework"
(June 2005, with Rod Johnson, Juergen Hoeller, Colin Sampaleanu and
Thomas Risberg)
http://www.amazon.com/exec/obidos/ASIN/0764574833/
Interface21 NL B.V.
Donker Curtiusstraat 7-400c
1051JL Amsterdam
Phone: 020 486 20 36
Fax: 084 837 00 00
Mail: al...@in...
Skype: aarendsen
************************************ DISCLAIMER *********************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error please
notify the system manager. Please note that any views or opinions
presented in this email are solely those of the author and do not
necessarily represent those of the company. Finally, the recipient
should check this email and any attachments for the presence of
viruses. The company accepts no liability for any damage caused by
any virus transmitted by this email.
*********************************************************************
--__--__--
Message: 7
From: "Juergen Hoeller"
To:
Subject: Re: [Springframework-developer] Assumption about stack trace format and cacao
Date: Tue, 17 Jan 2006 18:48:28 +0100
Reply-To: spr...@li...
FYI, I've finally committed this change to CVS HEAD.
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Juergen Hoeller
Sent: Tuesday, January 17, 2006 1:01 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Assumption about stack trace format
and cacao
I've just refined Jdk13ControlFactory to take this into account.
This should still be pretty efficient, since it does indexOf with start
indexes now, iterating over the stacktrace to find a match without
subsequent parenthesis - then checking the character right after the method
name whether it's a parenthesis or whitespace, either returning "found" or
increasing the index accordingly for the next iteration.
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Olivier Jolly
Sent: Tuesday, January 17, 2006 10:39 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Assumption about stack trace format
and cacao
> Interesting issue. So for a simple fix, would this mean that we should
> also check for:
>
> this.stackTrace.indexOf(clazz.getName() + "." + methodName + " (")
> != -1
>
> With an extra space before the parenthesis?
Yes, exactly, that should do the trick nicely. I can confirm this later when
I'm home.
But, for performance issues, shouldn't it be better know which exact pattern
we're looking for ? If I understand right, the jdk13 way of doing is already
quite slow, it may hurt to make the situation worse ..
> Juergen
Olivier
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
--__--__--
Message: 8
Date: Tue, 17 Jan 2006 19:38:18 +0100
From: Olivier Jolly
To: spr...@li...
Subject: Re: [Springframework-developer] Assumption about stack trace
format and cacao
Reply-To: spr...@li...
Great,
I just tested and now it works fine.
Thank you
Olivier
Juergen Hoeller a =E9crit :
>FYI, I've finally committed this change to CVS HEAD.
>
>Juergen
>=20
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf=
Of
>Juergen Hoeller
>Sent: Tuesday, January 17, 2006 1:01 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Assumption about stack trace fo=
rmat
>and cacao
>
>I've just refined Jdk13ControlFactory to take this into account.=20
>
>This should still be pretty efficient, since it does indexOf with start
>indexes now, iterating over the stacktrace to find a match without
>subsequent parenthesis - then checking the character right after the met=
hod
>name whether it's a parenthesis or whitespace, either returning "found" =
or
>increasing the index accordingly for the next iteration.
>
>Juergen
>=20
>
--__--__--
Message: 9
Date: Wed, 18 Jan 2006 01:26:42 +0100 (CET)
From: al...@in...
To: spr...@li...
Subject: [Springframework-developer] spring build.398 Build Successful
Reply-To: spr...@li...
View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20060118001640Lbuild.398
--__--__--
=== message truncated ===
|
