springframework-developer — Spring Framework developers list

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Michael S. <mi...@sc...>]

On Tuesday 22 February 2005 23:47, Martin Kersten wrote:
> >> Also I would love to see Spring being applied to
> >> the 'Interface belongs to the client' design principle. :-)
> >
> > A faithful of the church of (Uncle) Bob, or so it seems ;-)
>
> Who is Bob? :-) I am with Fowler and Kent! ;-)

I was pretty sure, but apparently wrong nonetheless, that you were 
referring to Robert C. Martin, aka Uncle Bob.

In particular, I thought you had some of these principles in mind
<http://www.objectmentor.com/resources/listArticles?key=topic&topic=Design%20Principles>


> Applying the interface belongs to the client is like this.
> The ApplicationContext for me is the core component of the
> springframework the way I used to use it. Define a context and
> off you go. So where does the ApplicationContext  interface belongs
> to? Well it is about the org.springframework package. The
> springframework is the client being in need of the ApplicationContext
> to deliver use for the people.

I don't agree; at least I'm not convinced. For one thing, I've used 
parts of Spring without touching so much as a BeanFactory. To my mind, 
the Spring package structure is easy to follow. The level below 
org.springframework denotes some general concern that can be understood 
from the point of view of a developer using Spring. The packages below 
that are about more specific aspects or implementation.

As is, the package structure appears to be "taxonomically-inspired", it 
hierarchically groups related pieces. Whereas what you suggest is a 
"usage-inspired" grouping, where things that likely to be used together 
are put nearby.


> It is about focus of the people working within sub-projects. I often
> see usefull code being not pushed up the package hierarchie just
> because the lack of focus.

Let me suggest that the reason is not lack of focus, but a fundamentally 
different mindset regarding where things belong. I don't share your 
view and judging from Spring as it is, neither does the Spring team. In 
particular, I don't share the assumption that the deeper down the 
package hierarchy a class is located the less significant it is.


> PS: Nice reading section by the way. I would like to add that
> "Code Complete,2nd Edition"(++), "Mythical Man-Month"(+++),
> "Domain-Driven-Design" (+++!), "Death March" (++),
> "Software Project Survival Guide" (++) are also some great reads.

Except for "Death March" I've read them, DDD is actually there on the 
list and the others just didn't make it.

> PSS: Saidly but "Analyse Pattern" was the first and last book
> that Martin Fowler wrote about world analysation. I got a great
> lesson lately completly focused about analysation pattern and
> another one called requirement enginiering. That was mind
> altering, I can tell you! But there is no standard book about this!
> :-(

I have "Data and Reality" by William Kent unread at arms length. It's 
approaching 30 years of age, but I've seen some recommendations 
recently. In general, though, I think software development should not 
try to mimick ontology. Epistemology may be more like it, thus modeling 
how we interact with the world instead of how it is in itself. 
Incidentally, we appear to exchange positions here. Where above I 
favored a roughly "ontological/taxonomical" approach, in this regard I 
prefer "epistemological/usage-based". But I fear that's just idle 
theory...


Michael

-- 
Michael Schuerig                   The Fifth Rider of the Apocalypse
mailto:mi...@sc...         is a programmer.
http://www.schuerig.de/michael/

[Springframework-developer] FAILED BUILD: x86-solaris1 (last 30 lines included)

[Darren D. <da...@sh...>]

1109115117
FAILED
    [junit] Testcase: testEvaluate took 0,002 sec
    [junit] Testcase: testEvaluateString took 0 sec
    [junit] Testcase: testEvaluateInteger took 0,001 sec
    [junit] Testcase: testEvaluateBoolean took 0,001 sec
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,022 sec
    [junit] Testsuite: org.springframework.web.util.HtmlUtilsTests
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,022 sec

    [junit] Testcase: testHtmlEscape took 0 sec
    [junit] Testcase: testHtmlUnescape took 0,001 sec
    [junit] Tests run: 6, Failures: 0, Errors: 1, Time elapsed: 0,097 sec
    [junit] Testsuite: org.springframework.web.util.Log4jWebConfigurerTests
    [junit] Tests run: 6, Failures: 0, Errors: 1, Time elapsed: 0,097 sec

    [junit] Testcase: testInitLoggingWithClasspath took 0,023 sec
    [junit] Testcase: testInitLoggingWithRelativeFilePath took 0,003 sec
    [junit] Testcase: testInitLoggingWithAbsoluteFilePath took 0,006 sec
    [junit] Testcase: testInitLoggingWithClasspathAndRefreshInterval took 0,005 sec
    [junit] Testcase: testInitLoggingWithRelativeFilePathAndRefreshInterval took 0,006 sec
    [junit] Testcase: testInitLoggingWithAbsoluteFilePathAndRefreshInterval took 0,01 sec
    [junit] 	Caused an ERROR
    [junit] Invalid 'log4jConfigLocation' parameter: Log4J config file [/home/users/d/da/davison/checkouts/spring/home/users/d/da/davison/checkouts/spring/target/x86-solaris1/test-classes/org/springframework/util/testlog4j.properties] not found
    [junit] java.lang.IllegalArgumentException: Invalid 'log4jConfigLocation' parameter: Log4J config file [/home/users/d/da/davison/checkouts/spring/home/users/d/da/davison/checkouts/spring/target/x86-solaris1/test-classes/org/springframework/util/testlog4j.properties] not found
    [junit] 	at org.springframework.web.util.Log4jWebConfigurer.initLogging(Log4jWebConfigurer.java:153)
    [junit] 	at org.springframework.web.util.Log4jWebConfigurerTests.doTestInitLogging(Log4jWebConfigurerTests.java:78)
    [junit] 	at org.springframework.web.util.Log4jWebConfigurerTests.testInitLoggingWithAbsoluteFilePathAndRefreshInterval(Log4jWebConfigurerTests.java:64)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    [junit] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

Re: [Springframework-developer] CVS (again)

[Nick M. <nic...@gm...>]

java.net is abominable...
There should be awards for the Software with the Most Miserable UI.
Collab.net would give most IBM products a run for their money. It
seems specifically designed to make it impossible to find the simplest
thing.

Move to codehaus and get it over with - just need to get somone to invite you...

-Nick


On Tue, 22 Feb 2005 10:39:41 -0700, Matt Raible <li...@ra...> wrote:
> 
> On Feb 22, 2005, at 4:00 AM, Martin Kersten wrote:
> 
> >>>> the performance of CVS seems so awful I can't even get updates
> >>>> properly now
> >>>> from the SSH servers.  Anyone else having difficulty?
> >
> >>> I always have problems with the CVS
> >
> >> at least we're not the only ones.  There are loads of recent support
> >> issues
> >> logged https://sourceforge.net/tracker/?group_id=1&atid=200001 -
> >> including one
> >> or two from frustrated users saying they're going to move from SF if
> >> they
> >> don't fix it properly this time or provide subversion instead.
> >
> >> I've now got a completely borked local tree due to several failed
> >> updates this
> >> morning :(
> >
> > How about moving to codehaus.org? :-)
> 
> I've moved to java.net a while ago because of the CVS issues at SF.
> Haven't really had any issues since moving.  java.net does kinda suck
> though because you only get one module per project - unlike SF where
> you get your own CVSROOT.
> 
> Matt
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Martin K. <Mar...@St...>]

>> Also I would love to see Spring being applied to
>> the 'Interface belongs to the client' design principle. :-)
>
> A faithful of the church of (Uncle) Bob, or so it seems ;-)

Who is Bob? :-) I am with Fowler and Kent! ;-)

> If I understand you correctly, you bemoan that currently abstractions,
> i.e. interfaces, and their implementations often live in the same
> package. This presumably results in these packages being off the
> mainline, meaning they are neither abstract and stable, nor concrete
> and instable.
>
> Your suggested solution is to move the abstractions to the packages
> where they are actually used. Thereby rendering their originating
> packages more concrete. Now, what would the outcome be? As most of the
> abstractions are used from multiple client packages, they can't be
> moved to any single one of them. Instead, new "abstract" packages would
> have to be created for them.

Nope! Look at the ApplicationContext within the package *.context.

Applying the interface belongs to the client is like this.
The ApplicationContext for me is the core component of the
springframework the way I used to use it. Define a context and
off you go. So where does the ApplicationContext  interface belongs to?
Well it is about the org.springframework package. The springframework
is the client being in need of the ApplicationContext to deliver use for the
people.

When defining a library the library root module becomes the client.
It's that simple. In our example moving ApplicationContext to
org.springframework where it belongs to, you state to the user of the
framework that everything of the sub packages is somewhat related to
this interface. So the whole context-subpackage becomes a package
only existing to implement the features the application context promises
the user of the framework.

That's it. And when you do this consistently among the whole
framework you wouldn't see this explosion of sub.packages.

AOP is a real difficult modul. It is more like a utility modul I guess.
It provides help everywhere. Thats the nature of aspect oriented
programming, I guess.

Also the seperation of subprojects becomes natural. For example
if you try to pull out some client interfaces of the web modul and
justify the existence within the org.springframework package,
you simply fail. It's somewhat special. Thats the point to tip your
toe and split the project into main and sub-project.

> Yes, this change would probably improve the scores on some design
> metric. Still, I'm somewhat sceptical if improvements of, say,
> learnability or maintainability would ensue. Also, as a matter of fact,
> Spring packages are not released individually, thus it is not very
> important to keep their interdependencies low. -- Your turn.

It is about focus of the people working within sub-projects. I often
see usefull code being not pushed up the package hierarchie just
because the lack of focus. It doesn't look like web push it up.
Somewhere would be the right place. But this doesn't happen often
when you deal with string manipulation etc. I dont know how it
is in terms of Spring since it is only providing some kind of coupling
and not implementation. Maybe the duplication in functionality (not code!)
is not that bad.

Martin (Kersten)

PS: Nice reading section by the way. I would like to add that
"Code Complete,2nd Edition"(++), "Mythical Man-Month"(+++),
"Domain-Driven-Design" (+++!), "Death March" (++),
"Software Project Survival Guide" (++) are also some great reads.

PSS: Saidly but "Analyse Pattern" was the first and last book
that Martin Fowler wrote about world analysation. I got a great
lesson lately completly focused about analysation pattern and
another one called requirement enginiering. That was mind
altering, I can tell you! But there is no standard book about this! :-(

> Michael Schuerig                           The more it stays the same,
> mailto:mi...@sc...                        The less it changes!
> http://www.schuerig.de/michael/      --Spinal Tap, The Majesty of Rock
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer 

[Springframework-developer] FAILED BUILD: sparc-solaris2 (last 30 lines included)

[Darren D. <da...@sh...>]

1109111649
FAILED
    [junit] Testcase: testEvaluate took 0,002 sec
    [junit] Testcase: testEvaluateString took 0 sec
    [junit] Testcase: testEvaluateInteger took 0,001 sec
    [junit] Testcase: testEvaluateBoolean took 0,001 sec
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,024 sec
    [junit] Testsuite: org.springframework.web.util.HtmlUtilsTests
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,024 sec

    [junit] Testcase: testHtmlEscape took 0 sec
    [junit] Testcase: testHtmlUnescape took 0,001 sec
    [junit] Tests run: 6, Failures: 0, Errors: 1, Time elapsed: 0,12 sec
    [junit] Testsuite: org.springframework.web.util.Log4jWebConfigurerTests
    [junit] Tests run: 6, Failures: 0, Errors: 1, Time elapsed: 0,12 sec

    [junit] Testcase: testInitLoggingWithClasspath took 0,033 sec
    [junit] Testcase: testInitLoggingWithRelativeFilePath took 0,005 sec
    [junit] Testcase: testInitLoggingWithAbsoluteFilePath took 0,005 sec
    [junit] Testcase: testInitLoggingWithClasspathAndRefreshInterval took 0,006 sec
    [junit] Testcase: testInitLoggingWithRelativeFilePathAndRefreshInterval took 0,005 sec
    [junit] Testcase: testInitLoggingWithAbsoluteFilePathAndRefreshInterval took 0,017 sec
    [junit] 	Caused an ERROR
    [junit] Invalid 'log4jConfigLocation' parameter: Log4J config file [/home/users/d/da/davison/checkouts/spring/home/users/d/da/davison/checkouts/spring/target/sparc-solaris2/test-classes/org/springframework/util/testlog4j.properties] not found
    [junit] java.lang.IllegalArgumentException: Invalid 'log4jConfigLocation' parameter: Log4J config file [/home/users/d/da/davison/checkouts/spring/home/users/d/da/davison/checkouts/spring/target/sparc-solaris2/test-classes/org/springframework/util/testlog4j.properties] not found
    [junit] 	at org.springframework.web.util.Log4jWebConfigurer.initLogging(Log4jWebConfigurer.java:153)
    [junit] 	at org.springframework.web.util.Log4jWebConfigurerTests.doTestInitLogging(Log4jWebConfigurerTests.java:78)
    [junit] 	at org.springframework.web.util.Log4jWebConfigurerTests.testInitLoggingWithAbsoluteFilePathAndRefreshInterval(Log4jWebConfigurerTests.java:64)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    [junit] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Michael S. <mi...@sc...>]

On Tuesday 22 February 2005 17:11, Martin Kersten wrote:
> Also I would love to see Spring being applied to
> the 'Interface belongs to the client' design principle. :-)

A faithful of the church of (Uncle) Bob, or so it seems ;-)

If I understand you correctly, you bemoan that currently abstractions, 
i.e. interfaces, and their implementations often live in the same 
package. This presumably results in these packages being off the 
mainline, meaning they are neither abstract and stable, nor concrete 
and instable.

Your suggested solution is to move the abstractions to the packages 
where they are actually used. Thereby rendering their originating 
packages more concrete. Now, what would the outcome be? As most of the 
abstractions are used from multiple client packages, they can't be 
moved to any single one of them. Instead, new "abstract" packages would 
have to be created for them.

Yes, this change would probably improve the scores on some design 
metric. Still, I'm somewhat sceptical if improvements of, say, 
learnability or maintainability would ensue. Also, as a matter of fact, 
Spring packages are not released individually, thus it is not very 
important to keep their interdependencies low. -- Your turn.

Michael

-- 
Michael Schuerig                           The more it stays the same,
mailto:mi...@sc...                        The less it changes!
http://www.schuerig.de/michael/      --Spinal Tap, The Majesty of Rock

Re: [Springframework-developer] JMX Documentation or Sample

[Dmitriy K. <dko...@ru...>]

>
>
> I'm assuming the MBeanAdapter is the MBeanExporter?
>
I believe so. I think Juergen refactored it 'MBeanAdapter -> MBeanExporter'

Dmitriy.

Re: [Springframework-developer] JMX Documentation or Sample

[Scott B. <sco...@ru...>]

Mike, Thomas,

Those are perfect resources.  Thanks!

Maybe the Wiki can be updated with this information for anyone else 
looking for it?

I'm assuming the MBeanAdapter is the MBeanExporter?

Thanks

-Scott



Michael Schuerig wrote:

>On Tuesday 22 February 2005 21:26, Scott Battaglia wrote:
>
>  
>
>>Okay, I'll look for them after the 1.1.5 release then!  In the mean
>>time are any of the test cases a good kind of guide to follow? I'm
>>not too familar with JMX so I'm learning JMX and trying to figure out
>>the Spring support at the same time (probably not a good
>>combination).
>>    
>>
>
>If all you want to do is expose a Spring bean as an MBean it's actually 
>pretty easy and doesn't require any code.
>
>Create an MBeanServer registered as a bean
>
>  <bean id="mbeanserver"
>   class="org.springframework.jmx.factory.MBeanServerFactoryBean">
>    <property name="defaultDomain"><value>MyDomain</value></property>
>  </bean>
>
>Wrap an MBean adapter around my repositorymanager bean (not shown), 
>which is a completely ordinary java object. In this case, public 
>methods are exposed as attributes/operations. Alternatively, metadata  
>can be used.
>
>  <bean id="mbeanadapter"
>   class="org.springframework.jmx.JmxMBeanAdapter">
>    <property name="server"><ref local="mbeanserver"/></property>
>    <property name="beans">
>      <map>
>        <entry key="MyDomain:id=Repository">
>          <ref bean="repositorymanager"/>
>        </entry>
>      </map>
>    </property>
>  </bean>
>
>Create a connector listening, by default, on 
>service:jmx:jmxmp://localhost:9876 (this requires 
>jmxremote_optional.jar)
>
>  <bean id="jmxconnector"
>    class="org.springframework.jmx.support.ConnectorServerFactoryBean">
>    <property name="server">
>      <ref local="mbeanserver" />
>    </property>
>    <!-- This is the default URL anyway -->
>    <property name="serviceUrl">
>      <value>service:jmx:jmxmp://localhost:9876</value>
>    </property>
>    <property name="threaded">
>      <value>true</value>
>    </property>
>    <!-- Ensure the connector thread doesn't keep the
>         servlet container running -->
>    <property name="daemon">
>      <value>true</value>
>    </property>
>  </bean>
>
>
>HTH,
>Michael
>
>  
>

Re: [Springframework-developer] JMX Documentation or Sample

[Michael S. <mi...@sc...>]

On Tuesday 22 February 2005 21:26, Scott Battaglia wrote:

> Okay, I'll look for them after the 1.1.5 release then!  In the mean
> time are any of the test cases a good kind of guide to follow? I'm
> not too familar with JMX so I'm learning JMX and trying to figure out
> the Spring support at the same time (probably not a good
> combination).

If all you want to do is expose a Spring bean as an MBean it's actually=20
pretty easy and doesn't require any code.

Create an MBeanServer registered as a bean

=A0 <bean id=3D"mbeanserver"
=A0 =A0class=3D"org.springframework.jmx.factory.MBeanServerFactoryBean">
=A0 =A0 <property name=3D"defaultDomain"><value>MyDomain</value></propert=
y>
=A0 </bean>

Wrap an MBean adapter around my repositorymanager bean (not shown),=20
which is a completely ordinary java object. In this case, public=20
methods are exposed as attributes/operations. Alternatively, metadata =A0
can be used.

=A0 <bean id=3D"mbeanadapter"
=A0 =A0class=3D"org.springframework.jmx.JmxMBeanAdapter">
=A0 =A0 <property name=3D"server"><ref local=3D"mbeanserver"/></property>
=A0 =A0 <property name=3D"beans">
=A0 =A0 =A0 <map>
=A0 =A0 =A0 =A0 <entry key=3D"MyDomain:id=3DRepository">
=A0 =A0 =A0 =A0 =A0 <ref bean=3D"repositorymanager"/>
=A0 =A0 =A0 =A0 </entry>
=A0 =A0 =A0 </map>
=A0 =A0 </property>
=A0 </bean>

Create a connector listening, by default, on=20
service:jmx:jmxmp://localhost:9876 (this requires=20
jmxremote_optional.jar)

  <bean id=3D"jmxconnector"
    class=3D"org.springframework.jmx.support.ConnectorServerFactoryBean">
    <property name=3D"server">
      <ref local=3D"mbeanserver" />
    </property>
    <!-- This is the default URL anyway -->
    <property name=3D"serviceUrl">
      <value>service:jmx:jmxmp://localhost:9876</value>
    </property>
    <property name=3D"threaded">
      <value>true</value>
    </property>
    <!-- Ensure the connector thread doesn't keep the
         servlet container running -->
    <property name=3D"daemon">
      <value>true</value>
    </property>
  </bean>


HTH,
Michael

--=20
Michael Schuerig                       Face reality and stare it down
mailto:mi...@sc...        --Jethro Tull, Silver River Turning
http://www.schuerig.de/michael/

[Springframework-developer] Re: Destroying Beans on Reverse of Creation Order?

[Seth L. <set...@gm...>]

On Tue, 22 Feb 2005 08:40:25 -1000, Seth Ladd <set...@gm...> wrote:
> Hello,
> 
> I saw this issue mentioned before in JIRA:
> 
> http://opensource.atlassian.com/projects/spring/browse/SPR-324
> 
> I believe I have a situation that exposes a bug or weakness in the destroy code.
> 
> I posted my explanation to the above issue.  I was hoping someone
> could check it out and see if I'm interpreting the situation
> correctly?  I believe that beans should be destroyed in reverse order
> of their creation order.  Is this the case?

I think I solved the problem, and it looks like Spring is doing
everything correctly!

The problem detailed above manifested itself from extensive use of
threading.  So one thread was being kicked off from inside a managed
bean.  Its lifecycle, of course, was not being managed by the
container.

All good now, sorry for the interruptions. :)

Seth
-- 
<a href="http://www.picklematrix.net/foaf.rdf">Seth Ladd's FOAF</a>
<a href="http://www.foaf-project.org/">What is FOAF?</a>

Re: [Springframework-developer] CVS (again)

[Matthew E. P. <mat...@me...>]

CVS issues at SourceForge.net have been going on for over 2 years.  
They come and go every few weeks.

I remember moving a project to java.net solely because of CVS issues at 
SF.


Cheers,
   Matthew


On Feb 22, 2005, at 12:09 PM, Martin Kersten wrote:

>>>>>> the performance of CVS seems so awful I can't even get updates 
>>>>>> properly now
>>>>>> from the SSH servers.  Anyone else having difficulty?
>>>
>>>>> I always have problems with the CVS
>>>
>>>> at least we're not the only ones.  There are loads of recent 
>>>> support issues
>>>> logged https://sourceforge.net/tracker/?group_id=1&atid=200001 - 
>>>> including one
>>>> or two from frustrated users saying they're going to move from SF 
>>>> if they
>>>> don't fix it properly this time or provide subversion instead.
>>>
>>>> I've now got a completely borked local tree due to several failed 
>>>> updates this
>>>> morning :(
>>>
>>> How about moving to codehaus.org? :-)
>> I've moved to java.net a while ago because of the CVS issues at SF.  
>> Haven't really had any issues since moving.  java.net does kinda suck 
>> though because you only get one module per project - unlike SF where 
>> you get your own CVSROOT.
>
> The codehaus people are great buddies. It isn't a huge site, quite
> familiar. :-) And Spring would meet their special focus I guess but 
> who cares? I guess the SF dudes are tackling this problem right now.
> Maybe it is solved this week. I heared that they move some server
> but I am not quite sure... .
>
>
> Cheers,
> Martin (Kersten)
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] JMX Documentation or Sample

[<tho...@tr...>]

Craig Walls JMX blog entry might get you started -
http://www.jroller.com/page/habuma/20040812

Thomas


Quoting Scott Battaglia <sco...@ru...>:

> Rob,
>
> Okay, I'll look for them after the 1.1.5 release then!  In the mean time
> are any of the test cases a good kind of guide to follow? I'm not too
> familar with JMX so I'm learning JMX and trying to figure out the Spring
> support at the same time (probably not a good combination).
>
> Thanks
> -Scott
>
> Rob Harrop wrote:
>
> > Scott,
> >
> > Once the 1.1.5 release is done, I'll be putting the JMX docs into CVS.
> > I have some stuff in Word and Costin Leau is finishing it up and will
> > probably translate it into DocBook.
> >
> > Rob
> >
> > Scott Battaglia wrote:
> >
> >> Is there a sample of the JMX stuff in CVS anywhere?  I tried
> >> following the Wiki document but it seems out of date.
> >>
> >> Thanks
> >> -Scott
> >>
> >>
> >> -------------------------------------------------------
> >> SF email is sponsored by - The IT Product Guide
> >> Read honest & candid reviews on hundreds of IT Products from real users.
> >> Discover which products truly live up to the hype. Start reading now.
> >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >> _______________________________________________
> >> Springframework-developer mailing list
> >> Spr...@li...
> >> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] JMX Documentation or Sample

[Scott B. <sco...@ru...>]

Rob,

Okay, I'll look for them after the 1.1.5 release then!  In the mean time 
are any of the test cases a good kind of guide to follow? I'm not too 
familar with JMX so I'm learning JMX and trying to figure out the Spring 
support at the same time (probably not a good combination).

Thanks
-Scott

Rob Harrop wrote:

> Scott,
>
> Once the 1.1.5 release is done, I'll be putting the JMX docs into CVS. 
> I have some stuff in Word and Costin Leau is finishing it up and will 
> probably translate it into DocBook.
>
> Rob
>
> Scott Battaglia wrote:
>
>> Is there a sample of the JMX stuff in CVS anywhere?  I tried 
>> following the Wiki document but it seems out of date.
>>
>> Thanks
>> -Scott
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] JMX Documentation or Sample

[Rob H. <ro...@ca...>]

Scott,

Once the 1.1.5 release is done, I'll be putting the JMX docs into CVS. I 
have some stuff in Word and Costin Leau is finishing it up and will 
probably translate it into DocBook.

Rob

Scott Battaglia wrote:

> Is there a sample of the JMX stuff in CVS anywhere?  I tried following 
> the Wiki document but it seems out of date.
>
> Thanks
> -Scott
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

[Springframework-developer] JMX Documentation or Sample

[Scott B. <sco...@ru...>]

Is there a sample of the JMX stuff in CVS anywhere?  I tried following 
the Wiki document but it seems out of date.

Thanks
-Scott

[Springframework-developer] Destroying Beans on Reverse of Creation Order?

[Seth L. <set...@gm...>]

Hello,

I saw this issue mentioned before in JIRA:

http://opensource.atlassian.com/projects/spring/browse/SPR-324

I believe I have a situation that exposes a bug or weakness in the destroy code.

I posted my explanation to the above issue.  I was hoping someone
could check it out and see if I'm interpreting the situation
correctly?  I believe that beans should be destroyed in reverse order
of their creation order.  Is this the case?

Thanks very much!
Seth

-- 
<a href="http://www.picklematrix.net/foaf.rdf">Seth Ladd's FOAF</a>
<a href="http://www.foaf-project.org/">What is FOAF?</a>

[Springframework-developer] FAILED BUILD: x86-linux2 (last 30 lines included)

[Darren D. <da...@sh...>]

1109096651
FAILED
    [junit] Testcase: testEvaluate took 0,001 sec
    [junit] Testcase: testEvaluateString took 0 sec
    [junit] Testcase: testEvaluateInteger took 0,001 sec
    [junit] Testcase: testEvaluateBoolean took 0,001 sec
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,012 sec
    [junit] Testsuite: org.springframework.web.util.HtmlUtilsTests
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,012 sec

    [junit] Testcase: testHtmlEscape took 0,001 sec
    [junit] Testcase: testHtmlUnescape took 0 sec
    [junit] Tests run: 6, Failures: 0, Errors: 1, Time elapsed: 0,087 sec
    [junit] Testsuite: org.springframework.web.util.Log4jWebConfigurerTests
    [junit] Tests run: 6, Failures: 0, Errors: 1, Time elapsed: 0,087 sec

    [junit] Testcase: testInitLoggingWithClasspath took 0,034 sec
    [junit] Testcase: testInitLoggingWithRelativeFilePath took 0,004 sec
    [junit] Testcase: testInitLoggingWithAbsoluteFilePath took 0,005 sec
    [junit] Testcase: testInitLoggingWithClasspathAndRefreshInterval took 0,005 sec
    [junit] Testcase: testInitLoggingWithRelativeFilePathAndRefreshInterval took 0,005 sec
    [junit] Testcase: testInitLoggingWithAbsoluteFilePathAndRefreshInterval took 0,006 sec
    [junit] 	Caused an ERROR
    [junit] Invalid 'log4jConfigLocation' parameter: Log4J config file [/var/local/home/users/d/da/davison/checkouts/spring/var/local/home/users/d/da/davison/checkouts/spring/target/x86-linux2/test-classes/org/springframework/util/testlog4j.properties] not found
    [junit] java.lang.IllegalArgumentException: Invalid 'log4jConfigLocation' parameter: Log4J config file [/var/local/home/users/d/da/davison/checkouts/spring/var/local/home/users/d/da/davison/checkouts/spring/target/x86-linux2/test-classes/org/springframework/util/testlog4j.properties] not found
    [junit] 	at org.springframework.web.util.Log4jWebConfigurer.initLogging(Log4jWebConfigurer.java:153)
    [junit] 	at org.springframework.web.util.Log4jWebConfigurerTests.doTestInitLogging(Log4jWebConfigurerTests.java:78)
    [junit] 	at org.springframework.web.util.Log4jWebConfigurerTests.testInitLoggingWithAbsoluteFilePathAndRefreshInterval(Log4jWebConfigurerTests.java:64)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    [junit] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

Re: [Springframework-developer] CVS (again)

[Martin K. <Mar...@St...>]

>>>>> the performance of CVS seems so awful I can't even get updates 
>>>>> properly now
>>>>> from the SSH servers.  Anyone else having difficulty?
>>
>>>> I always have problems with the CVS
>>
>>> at least we're not the only ones.  There are loads of recent support 
>>> issues
>>> logged https://sourceforge.net/tracker/?group_id=1&atid=200001 - 
>>> including one
>>> or two from frustrated users saying they're going to move from SF if 
>>> they
>>> don't fix it properly this time or provide subversion instead.
>>
>>> I've now got a completely borked local tree due to several failed 
>>> updates this
>>> morning :(
>>
>> How about moving to codehaus.org? :-)
> 
> I've moved to java.net a while ago because of the CVS issues at SF.  
> Haven't really had any issues since moving.  java.net does kinda suck 
> though because you only get one module per project - unlike SF where 
> you get your own CVSROOT.

The codehaus people are great buddies. It isn't a huge site, quite
familiar. :-) And Spring would meet their special focus I guess but 
who cares? I guess the SF dudes are tackling this problem right now.
Maybe it is solved this week. I heared that they move some server
but I am not quite sure... .


Cheers, 

Martin (Kersten)

[Springframework-developer] About BeanDefinitionHolder

[Martin K. <Mar...@St...>]

Hi there,

   I am not sure but what exactly is a bean definiton holder?
I guess it is storing a bean definition and stores the bean name
and the aliases. 

It has only get methods. First of all its main task seams to 
store the bean definition. That means it is a BeanDescription?
Well this would make more sence since this one does not
hold anything (can't spot any hold method).

I think I start to understand how this is all wired up internally.
Lots of reversed responsibility if you ask me.


Martin (Kersten)

Re: [Springframework-developer] CVS (again)

[Matt R. <li...@ra...>]

On Feb 22, 2005, at 4:00 AM, Martin Kersten wrote:

>>>> the performance of CVS seems so awful I can't even get updates 
>>>> properly now
>>>> from the SSH servers.  Anyone else having difficulty?
>
>>> I always have problems with the CVS
>
>> at least we're not the only ones.  There are loads of recent support 
>> issues
>> logged https://sourceforge.net/tracker/?group_id=1&atid=200001 - 
>> including one
>> or two from frustrated users saying they're going to move from SF if 
>> they
>> don't fix it properly this time or provide subversion instead.
>
>> I've now got a completely borked local tree due to several failed 
>> updates this
>> morning :(
>
> How about moving to codehaus.org? :-)

I've moved to java.net a while ago because of the CVS issues at SF.  
Haven't really had any issues since moving.  java.net does kinda suck 
though because you only get one module per project - unlike SF where 
you get your own CVSROOT.

Matt

Re: [Springframework-developer] Adding Contribution support

[Martin K. <Mar...@St...>]

Hi Andy,

> If Spring wanted to automate this "extension point" mechanism such as it
> exists in our project, it could provide something like this:
>
> <bean id="modelManager" class="...">
>  <property name="modelSources" 
> extension-point="com.mypackage.ModelSource"/>
> </bean>
>
> Which would automatically build a collection by gathering all beans that
> implement the specified interface and injecting the collection into the
> "modelSources" property.

Thats an nice idea. But you have to name the contribution. Also
refactoring the DefaultXmlBeanDefinitionParser I have learned,
that all which is needed is to add another parser to support
extensions.

Currently I am thinking of a more extense usage of the extension
point mechanism, quite like Eclipse offers.

<contribution extension-point="ep">
    <any tag you want>
</contribution>

The idea is to flexiblize the contribution process. The question is what
the dtd says to it.
In Eclipse there is some kine of rule:
   If you dont apply to the extension point policy, then we will ignore you.

That would make the whole thing more contributional like. So you can
describe contributions by not adding any class.
(which makes sometimes a lot of scence). Also it should be possible
to contribute in any description as you would like. There should be
support for the default way to inject bean dependencies. But maybe
I have to leave this task to extension-point stakeholder until I know
for sure.

But back on refactoring. It makes fun but I can not run test cases.
I am starting to get nervous. :-)


Cheers,

Martin (Kersten) 

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

[<tho...@tr...>]

I think it makes sense to have DeadlockLoserDataAccessException being a subclass
of ConcurrencyFailureException.  Then you would only have to catch this
exception before retrying the operation.

The esiest way to handle this in the translation is to set the
"customTranslations" property on the "SQLErrorCodes" like:

<bean id="Sybase" class="org.springframework.jdbc.support.SQLErrorCodes">
...
  <property name="badSqlGrammarCodes">
  ...
  </property>
  <property name="dataIntegrityViolationCodes">
  ...
  </property>
  ...
  <property name="customTranslations">
    <list>
      <bean
        class="org.springframework.jdbc.support.CustomSQLErrorCodesTranslation">
        <property name="errorCodes">
          <value>1205</value></property>
        <property name="exceptionClass">
         
<value>org.springframework.dao.DeadlockLoserDataAccessException</value>
        </property>
      </bean>
    </list>
  </property>
  ...
</bean>


Thomas



Quoting Pierre Bittner <pie...@gm...>:

> Hi Juergen,
>
> In our project, we use an implementation of SQLExceptionTranslator  to
> translate sybase error code '1205' in
> DeadlockLoserDataAccessException.
>
> >From sybase documentation:
>
> "This error occurs when a process tries to acquire a lock on an object
> that is locked by a second process when the second process is waiting
> for a lock on an object that has been locked by the first process.
> This situation is a deadlock, and can involve more than two processes.
>
> Adaptive Server detects this situation, rolls back the transaction
> that has accumulated the least amount of CPU time, and notifies the
> application program of this action with Error 1205. This allows the
> other users' processes to move forward."
>
> We catch the DeadlockLoserDataAccessException in an ExceptionHandler
> and display a warning to user.
>
> Hope this helps.
>
> Pierre
>
> On Tue, 22 Feb 2005 13:12:23 +0100, Juergen Hoeller
> <ju...@in...> wrote:
> > Thomas, everybody,
> >
> > Please have a look at the following JIRA issue:
> > http://opensource.atlassian.com/projects/spring/browse/SPR-733
> >
> > I agree that DeadlockLoserDataAccessException should be a subclass of
> > ConcurrencyFailureException (which has been introduced in Spring 1.1), and
> > have already changed this locally.
> >
> > However, DeadlockLoserDataAccessException isn't thrown anywhere;
> > SQLErrorCodes does not support it. So as indicated in SPR-733, should we
> > generally throw CannotAcquireLockException in such a case (which currently
> > seems to happen for some databases, as defined in sql-error-codes.xml)?
> > What's the semantic difference between those two exceptions, and is it
> worth
> > keeping both?
> >
> > Juergen
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Martin K. <Mar...@St...>]

Sorry guys, pressed Ctrl+Enter while marking something and Outlook send
the unfinished post. Sorry.


> Which sounds similar to the contents of the current spring-core.jar to me,
> although there you get only the beanfactory support. For application 
> contexts,
> you have to use the spring-context.jar, which has a bunch of other,
> related stuff in it (ejb, jms etc.).

> The problem is, your definition of how to split modules is unlikely to
> be the same as mine, and mine will doubtless differ from the next x
> users you happen to ask.

 That's the problem but one reason to split is target domain. Web is
 considered to be a domain. Also I am quite sure orm should be
replaced to persisting/persistence. ORM is a certain kind of a solution
and so is JDBC. So we are talking about two solutions of the
persistance problem.

-> *.persistence.jdbc, *.persistence.orm (or database or whatever)

 -> Subproject: Web, Persistence (DB), Rich Client,
    J2EE (considered to be a special domain by Sun, J2SE vs J2EE).

> Where is AOP in your scenario?
Part of all worlds. Aspect orientated programming is a way of thinking and
about seperation of concerns -> Just addition to java.
General audiance.-> core/main project.

> JDO but not HIbernate?

 When you try to hire a developer for JDO or Hibernate task,
 what would you request? General Java developer?

> Spring is already divided into 8 smaller jars, which seem to
> have a reasonable compromise of grouped related features.

 The dependencies arnt. And so why don't you want to have
 1Main + 3 sub projects? What do you want to do if Spring RPC is

> I can't really comment on this as all I use is spring.jar, but doubtless 
> they are ideal for some users and useless for others, but I don't see a 
> huge amount of value in hashing and rehashing what should and shouldn't be 
> in them. I do think those jars should maybe be made available for download 
> separately, rather than having to get the whole spring distribution, 
> source and all, just to get hold of eg. spring-core.jar.

Maybe. You can't even repackage the Spring API within 1.1.4 anyways.
Only Spring 2.x may be repackaged. And that will take ages until this
opportunity really comes.


Cheers,

Martin (Kersten)


> From: spr...@li... on behalf of 
> Martin Kersten
> Sent: Tue 22/02/2005 14:56
> To: spr...@li...
> Subject: Re: [Springframework-developer] I don't like the 
> DefaultXmlBeanDefinitionParser
>
>
>
>> The distribution comes with different JARs for different circumstances,
>> but it might be nice to be able to download them separately as well.
>
> How does web fits the vision of the core framework? It's really an
> issue. Would you also like to deliver the rich client platform
> and it's dependency also within the framework?
>
> But downloading the required jars based on the case scenario
> the user has would be a great improvement anyways. For my
> current research I would like to had the option to get a
> web free, jdbc free, jms free, mail free, orm free, remoting free,
> transaction free Spring version.
>
> If I would be in charge I would split it up the following way:
>
> core, web, j2ee, persistence, later rpc.
>
>
> Cheers,
>
> Martin (Kersten)
>
>
>>
>> Rob
>>
>> Martin Kersten wrote:
>>
>>>> My thoughts exactly :). We have enough dependencies already.
>>>
>>>
>>> You should break up your framework anyways.
>>>
>>> You are currently providing a 'Jack of all trades' API. A solution
>>> for everything but nothing in particular.
>>>
>>> Don't get mad :-) Here is what I mean:
>>>
>>> Spring adapts services for many diffrent situations:
>>>  You having a web application, fine download the
>>>      default spring framework,
>>>  You have a command line application, fine download
>>>       the default spring framework
>>>
>>>  If it's not in the framework, we dont support it.
>>>
>>> Thats what I mean. Download the framework and be happy.
>>>
>>> It's like java, download the SE and you have all the stuff those
>>> folks think some (!) people might(!) wanna have.
>>>
>>> How about making a core framework and having extensions.
>>>
>>> So you go for a normal application, just download the core
>>> framework. You want to go for a web application, download
>>> the core framework and download the web extension.
>>>
>>> You know I am currently trying to get my visions into the RPC
>>> sub project. And when you start to develop your own
>>> rich client(!) guess what, you have code for setting up a web
>>> application right out of the box!
>>>
>>> Imagen what a relieve it would be for all of you folks to speak
>>> about extensions and the core project, manage the dependencies
>>> for those individually. Imagen having more then one swing reference
>>> documentation. One for the core, one for the web, one for RPC and
>>> so on. Boy I would be lucky if I were you :-).
>>>
>>>
>>> Martin (Kersten)
>>>
>>> PS: Just a hint! ;-)
>>>
>>>> Erwin Vervaet wrote:
>>>>
>>>>> I think the main reason to use the W3C DOM API directly is to avoid 
>>>>> the
>>>>> need for an extra dependency (e.g. JDOM) just to parse the XML bean
>>>>> definitions. You end up with an "less than elegant" implementation in
>>>>> DefaultXmlBeanDefinitionParser, but in this case the benifits outweigh
>>>>> the costs.
>>>>>  Erwin Vervaet
>>>>> erw...@er... <mailto:erw...@er...>
>>>>>
>>>>>     ----- Original Message -----
>>>>>     *From:* Martin Kersten
>>>>>     <mailto:Mar...@St...>
>>>>>     *To:* spr...@li...
>>>>>     <mailto:spr...@li...>
>>>>>     *Sent:* Tuesday, February 22, 2005 1:21 PM
>>>>>     *Subject:* [Springframework-developer] I don't like the
>>>>>     DefaultXmlBeanDefinitionParser
>>>>>
>>>>>     Hi folks,
>>>>>      I am currently trying to extend the framework by supporting
>>>>>     contributions.
>>>>>     Just to see how it feels.
>>>>>      So I made some investigations in the sourcecode. I don't want to
>>>>>     start a war
>>>>>     about proper design rules, since I am a believer in 'Interface
>>>>>     belongs to the
>>>>>     client' stuff and you are appearently not, but this isn't the
>>>>>     issue I want to
>>>>>     talk about.
>>>>>      Th implementation I hate most on first sight is the
>>>>>     XMLBeanDefinitionParser. I know it does what it should but you can
>>>>>     read this:
>>>>>      /**
>>>>>       * Make the horrible DOM API slightly more bearable:
>>>>>       * get the text value we know this element contains.
>>>>>       */
>>>>>      Well I would agree but it's a bit wired also. You think the DOM
>>>>>     API is horrible
>>>>>     and you are still using it? You know what it means to use a
>>>>>     horrible API? You write a horrible implementation! And thats how
>>>>>     it looks.
>>>>>     It took me more then a gaze to catch the meaning of the parser and
>>>>>     I also
>>>>>     got blown by the code duplication. Since I am in need to extend
>>>>>     this class,
>>>>>      So I would like to ask if I may refactor it and commit you a 
>>>>> patch
>>>>>     (or maybe
>>>>>     a complete reimplementation)?
>>>>>      Cheers,
>>>>>      Martin (Kersten)
>>>>>      PS: By the way, how about 'Hidding 3rd party library behind 
>>>>> single
>>>>>     interface?'
>>>>>
>>>>>         ----- Original Message -----
>>>>>         *From:* Martin Kersten
>>>>>         <mailto:Mar...@St...>
>>>>>         *To:* spr...@li...
>>>>>         <mailto:spr...@li...>
>>>>>         *Sent:* Tuesday, February 22, 2005 12:46 PM
>>>>>         *Subject:* Re: [Springframework-developer] Please check these
>>>>>         two things
>>>>>
>>>>>         Sorry, thought the agreement goes with the callee. Ok :-) 
>>>>> sorry
>>>>> was a strange day for me, I guess.
>>>>>          Thanks,
>>>>>          Martin (Kersten)
>>>>>         ----- Original Message -----
>>>>>
>>>>>             *From:* Juergen Hoeller <mailto:ju...@in...>
>>>>>             *To:* spr...@li...
>>>>>             <mailto:spr...@li...>
>>>>>             *Sent:* Tuesday, February 22, 2005 12:13 PM
>>>>>             *Subject:* Re: [Springframework-developer] Please check
>>>>>             these two things
>>>>>
>>>>>             Actually, I have *not* replaced this with a == comparison
>>>>>             of the arrays: Instead, BatchSqlUpdate is storing clones
>>>>>             of the passed-in arrays now, for execution on flush. This
>>>>>             avoids any side effects in the first place (even if the
>>>>>             passed-in arrays are changed afterwards or reused for
>>>>>             multiple update inovcations), and the overhead of cloning
>>>>>             an array should be acceptable (after all, we're talking
>>>>>             about database update operations here).
>>>>>              Juergen
>>>>>
>>>>>                 -----Original Message-----
>>>>>                 *From:*
>>>>>                 spr...@li...
>>>>>
>>>>> [mailto:spr...@li...]*On
>>>>>                 Behalf Of *Martin Kersten
>>>>>                 *Sent:* Tuesday, February 22, 2005 12:04 PM
>>>>>                 *To:* spr...@li...
>>>>>                 *Subject:* Re: [Springframework-developer] Please
>>>>>                 check these two things
>>>>>
>>>>>                 But isn't this bogus thinking? I mean replacing
>>>>>                 .equals with == makes
>>>>>                 the implementation more strickt and reduces semantical
>>>>>                 informations.
>>>>>                 We are thinking about objects and there is no
>>>>>                 performance gap
>>>>>                 to justify this modification.
>>>>>                  I wouldn't do it. I just would ensure that equals
>>>>>                 implementations
>>>>>                 start with if(this==object) return true;. How huge is
>>>>>                 the estimated
>>>>>                 performance gain?
>>>>>
>>>>>                 Cheers,
>>>>>                  Martin (Kersten)
>>>>>
>>>>>                     ----- Original Message -----
>>>>>                     *From:* Juergen Hoeller
>>>>>                     <mailto:ju...@in...>
>>>>>                     *To:*
>>>>>                     spr...@li...
>>>>>
>>>>> <mailto:spr...@li...>
>>>>>
>>>>>                     *Sent:* Tuesday, February 22, 2005 10:06 AM
>>>>>                     *Subject:* Re: [Springframework-developer] Please
>>>>>                     check these two things
>>>>>
>>>>>                     Well-spotted!
>>>>>                      ConcurrencyThrottleInterceptor should indeed use
>>>>>                     an internal monitor to avoid any potential for
>>>>>                     side effects. I doubt that this has caused any
>>>>>                     issue in practice, but it's nevertheless cleaner.
>>>>>                      That check in BatchSqlUpdate is not supposed to
>>>>>                     compare the elements but just the array reference:
>>>>>                     Repeated update invocations should not pass-in the
>>>>>                     same array instance repeatedly, with modified
>>>>>                     elements. Of course, a == check would be
>>>>>                     sufficient for this. I've reworked that part a bit
>>>>>                     differently, though: BatchSqlUpdate stores a clone
>>>>>                     of the passed-in array now, so there shouldn't be
>>>>>                     a need for such a check anymore.
>>>>>                      Juergen
>>>>>
>>>>>                         -----Original Message-----
>>>>>                         *From:*
>>>>>
>>>>> spr...@li...
>>>>>
>>>>> [mailto:spr...@li...]*On
>>>>>                         Behalf Of *Dave Brosius
>>>>>                         *Sent:* Tuesday, February 22, 2005 8:08 AM
>>>>>                         *To:*
>>>>> 
>>>>> spr...@li...
>>>>>                         *Subject:* [Springframework-developer] Please
>>>>>                         check these two things
>>>>>
>>>>>                         These may be problems, and then again maybe
>>>>>                         not. But they seem odd/wrong to me
>>>>>                          1) In
>>>>>
>>>>> org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor
>>>>>                          in method invoke
>>>>>                          uses wait on 'this'
>>>>>                          In my mind you are exposing your
>>>>>                         synchronization strategies as a public
>>>>>                         artifact, which leaves this class open to
>>>>>                         failure due to client code.
>>>>>                         The client code may unwittingly us an instance
>>>>>                         of this class to do it's own synchronization,
>>>>>                         and totally screw up this class.
>>>>>                         I would recommend doing synchronizations
>>>>>                         (especially the use of wait/notify) on a
>>>>>                         private member so client code can not effect
>>>>> it.
>>>>>                          2) In
>>>>>                         org.springframework.jdbc.object.BatchSqlUpdate
>>>>>                          in method update, you do
>>>>>                          if (!this.parameterQueue.isEmpty() &&
>>>>>                         args.equals(this.parameterQueue.getLast())) {
>>>>>                          this is the same as using     args ==
>>>>>                         this.parameterQueue.getLast()
>>>>>                          or in other words, are these objects the same
>>>>>                         object. I assume you want to compare the
>>>>>                         elements of the array?
>>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> SF email is sponsored by - The IT Product Guide
>>>> Read honest & candid reviews on hundreds of IT Products from real 
>>>> users.
>>>> Discover which products truly live up to the hype. Start reading now.
>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>> _______________________________________________
>>>> Springframework-developer mailing list
>>>> Spr...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from real users.
>>> Discover which products truly live up to the hype. Start reading now.
>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
> ________________________________________________________________________
> This e-mail has been scanned for all viruses by Star. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit:
> http://www.star.net.uk
> ________________________________________________________________________
>
>
>
> ________________________________________________________________________
> This e-mail has been scanned for all viruses by Star. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit:
> http://www.star.net.uk
> ________________________________________________________________________
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer 

Re: [Springframework-developer] Adding Contribution support

[Andy D. <an...@ma...>]

I'm going to add my 2c and just throw in what we do.  Our rich client is 
modular, in the sense that if a customer pays for a certain module, then they 
get that functionality.  To easily support this we split each module into its 
own .jar.  Our goal is that if a module's .jar is on the classpath, then its 
"contributions" automatically becomes a part of the application.  Our server 
creates a WebStart .jnlp for each customer with their particular set of 
module .jars setup for their classpath.  Yes, this is basically nothing more 
than a plugin architecture we are talking about.
So, how do we approach this from a configuration standpoint, seeing that we've 
decided to use Spring and Spring-richclient?  Basically how Rob has 
described.  Each module can specify its own Spring configuration file.  We 
can automatically detect these by requiring all module .jars to have their 
Spring config in the same location and with the same name 
(META-INF/context.xml).  We then pass this into 
FileSystemXmlApplicationContext: "classpath*:/META-INF/context.xml"
At this point we have one big ApplicationContext containing all the beans for 
all modules.  We now need some way to meaningfully and dynamically connect 
the various beans together.  Modules do not directly reference beans from 
each other, because there is no guarantee that a module is going to be 
present - meaning I can't do something like this:

<bean id="modelManager" class="...">
  <property name="modelSources">
    <list>
      <ref bean="fooModuleModel"/>
      <ref bean="barModuleModel"/>
      ...
    </list>
  </property>
</bean>

because fooModuleModel and/or barModuleModel might not be present in the 
ApplicationContext.  So, we implement an idea that is similar in spirit to 
"extension points".  For each "extension point" we define a simple Java 
interface, and then the extension point "stakeholder" will query the 
ApplicationContext for beans implementing that interface:
        Map modelSources = 
BeanFactoryUtils.beansOfTypeIncludingAncestors(getApplicationContext(), 
ModelSource.class, false, false);
Which will rake in all beans implementing ModelSource.  The interface also 
defines a contract that an extension point contributor must implement in 
order to meaningfully "contribute" to the extension point.  Granted, it would 
be nice if Spring provided some automated way to perform this so I wouldn't 
have to create dependencies on Spring in my classes (ApplicationContext, 
getBeansOfType, etc).
If Spring wanted to automate this "extension point" mechanism such as it 
exists in our project, it could provide something like this:

<bean id="modelManager" class="...">
  <property name="modelSources" extension-point="com.mypackage.ModelSource"/>
</bean>

Which would automatically build a collection by gathering all beans that 
implement the specified interface and injecting the collection into the 
"modelSources" property.

  - Andy

PS In Spring, this whole idea is currently implemented in "recipe" fashion.  
IoC containers like HiveMind make the idea a first class citizen.  Actually, 
we considered HiveMind, but it is not as mature as Spring and doesn't offer 
many of the advanced integration constructs of Spring.

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

[Pierre B. <pie...@gm...>]

Hi Juergen,

In our project, we use an implementation of SQLExceptionTranslator  to
translate sybase error code '1205' in
DeadlockLoserDataAccessException.

From sybase documentation:

"This error occurs when a process tries to acquire a lock on an object
that is locked by a second process when the second process is waiting
for a lock on an object that has been locked by the first process.
This situation is a deadlock, and can involve more than two processes.

Adaptive Server detects this situation, rolls back the transaction
that has accumulated the least amount of CPU time, and notifies the
application program of this action with Error 1205. This allows the
other users' processes to move forward."

We catch the DeadlockLoserDataAccessException in an ExceptionHandler
and display a warning to user.

Hope this helps.

Pierre

On Tue, 22 Feb 2005 13:12:23 +0100, Juergen Hoeller
<ju...@in...> wrote:
> Thomas, everybody,
> 
> Please have a look at the following JIRA issue:
> http://opensource.atlassian.com/projects/spring/browse/SPR-733
> 
> I agree that DeadlockLoserDataAccessException should be a subclass of
> ConcurrencyFailureException (which has been introduced in Spring 1.1), and
> have already changed this locally.
> 
> However, DeadlockLoserDataAccessException isn't thrown anywhere;
> SQLErrorCodes does not support it. So as indicated in SPR-733, should we
> generally throw CannotAcquireLockException in such a case (which currently
> seems to happen for some databases, as defined in sql-error-codes.xml)?
> What's the semantic difference between those two exceptions, and is it worth
> keeping both?
> 
> Juergen