springframework-developer — Spring Framework developers list

RE: [Springframework-developer] Ready for 1.0 RC1

[<jue...@we...>]

Forgot to say, thanks to Thomas Achleitner for providing the initial =
version of ReloadableResourceBundleMessageSource!

(BTW, Thomas: Resource locations can now resolve system properties like =
${user.home} out of the box - no need for custom =
PropertyPlaceholderConfigurer subclasses anymore).

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Wednesday, February 04, 2004 8:11 PM
To: spr...@li...
Subject: [Springframework-developer] Ready for 1.0 RC1


Everybody,

I've committed my final reworkings for 1.0 RC1 one. Quite a few internal =
classes have moved between packages; there shouldn't be any major =
incompatilities. I've also incorporated most recent bug reports in the =
affected areas.

A new feature is ReloadableResourceBundleMessageSource: An alternative =
implementation of MessageSource that follows basic ResourceBundle =
conventions but is able to reload message definitions and to load the =
properties files from any resource location. This removes a major =
nuisance of java.util.ResourceBundle in a server environment: =
Effectively, message definitions can now be changed on-the-fly like JSPs =
or templates can, without losing a significant amount efficiency.

The "cacheSeconds" interval specifies the refresh interval: If the =
last-modified timestamp of the files hasn't changed, no reloading will =
occur. So "cacheSeconds" can be set to 1 without worrying about =
performance. My own rudimentary performance tests indicate that =
ReloadableResourceBundleMessageSource is twice as fast as the standard =
ResourceBundleMessageSource when caching forever, and still 40% faster =
with "cacheSeconds" =3D 1.

I'd like to encourage everybody to test the current CVS head thoroughly. =
I will test our sample apps myself too, against HSQLDB and MySQL, but =
I'm primarily talking of custom applications here. Please report any =
remaining issues promptly; I intend to release RC1 this weekend.

Juergen

P.S.:
Haven't had the time to look at the 96-beans issue; will do so tomorrow.


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
mailto:jue...@we...
http://www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Ready for 1.0 RC1

[<jue...@we...>]

Everybody,

I've committed my final reworkings for 1.0 RC1 one. Quite a few internal =
classes have moved between packages; there shouldn't be any major =
incompatilities. I've also incorporated most recent bug reports in the =
affected areas.

A new feature is ReloadableResourceBundleMessageSource: An alternative =
implementation of MessageSource that follows basic ResourceBundle =
conventions but is able to reload message definitions and to load the =
properties files from any resource location. This removes a major =
nuisance of java.util.ResourceBundle in a server environment: =
Effectively, message definitions can now be changed on-the-fly like JSPs =
or templates can, without losing a significant amount efficiency.

The "cacheSeconds" interval specifies the refresh interval: If the =
last-modified timestamp of the files hasn't changed, no reloading will =
occur. So "cacheSeconds" can be set to 1 without worrying about =
performance. My own rudimentary performance tests indicate that =
ReloadableResourceBundleMessageSource is twice as fast as the standard =
ResourceBundleMessageSource when caching forever, and still 40% faster =
with "cacheSeconds" =3D 1.

I'd like to encourage everybody to test the current CVS head thoroughly. =
I will test our sample apps myself too, against HSQLDB and MySQL, but =
I'm primarily talking of custom applications here. Please report any =
remaining issues promptly; I intend to release RC1 this weekend.

Juergen

P.S.:
Haven't had the time to look at the 96-beans issue; will do so tomorrow.


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
mailto:jue...@we...
http://www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG

[Springframework-developer] [PATCH] docs/reference/src/beans.xml

[Francois B. <fb...@us...>]

Hi !

I did a proofread of the first few chapters.  I did introduction,
background and beans.

I have attached a patch with corrections for the beans.xml file.  Accept
or reject as you see fit :)  There are a few misspellings corrections,
some rewordings, and a correction to the destroy method example.  I have
not reviewed the "BeanFactory structure and implementations"
(#beans-factoryimpl) section.  The comment says it needs a rewrite, so I
did not spend time on it.

Log message follows:
[[[
* docs/reference/src/beans.xml:
  Patch by Francois Beausoleil (fb...@us...).

  Corrects spelling mistakes, rewords some sentences, and
  corrects the destroy method example.

  The example was copied   from the init example, and it
  defined the destroy method as init, clearly a cut'n'paste
  error.  Also changed the destroy method name to something
  that didn't look like we implement DisposableBean.
]]]

I will go on with the other chapters as time permits.

Sorry for the attachment instead of inlining the patch, but my mailer
*will* wrap long lines, and the beans.xml file has long lines, so the
patch would have been "dead-on-arrival".  I preferred to avoid that.

I used the cvs unified diff format, created on Windows.

Bye !
Fran=E7ois Beausoleil
Developer of Java Gui Builder
http://jgb.sourceforge.net/

[Springframework-developer] Spring and Maven

[Alef A. <al...@jt...>]

Spring (m4) is available in the ibiblio repository:

http://www.ibiblio.org/maven/

Regards,

Alef


P.s. as soon as rc1 is released, I'll do another request to upload it.

Re: [Springframework-developer] Container Bean threshold?

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

Damn it, I told the guys that 96 beans wasn't enought, but they wouldn't 
listen to me...     

Just kidding. If somebody else doesn't get to it by then, I think I can 
look at this on Thurs...


Mike Cannon-Brookes wrote:

>Obviously this is a big problem to us right now (doh), as Confluence has
>just passed 96 beans in Spring (yay!).
>
>Charles and I have just been investigating in more detail, it seems that as
>soon as we add the _97th_ bean, one of our _circular_ references barfs.
>
>We'll investigate further - but any ideas as to where to look would be most
>appreciated :)
>
>Cheers,
>Mike
>
>PS It may also be some sort of a limit in the number of circular referenced
>beans, or singletons? I'm not sure.
>
>On 4/2/04 1:43 PM, "Ross Mason" (ro...@at...) penned the words:
>
>  
>
>>Hi guys,
>>
>>I've just found some interesting behaviour in the spring container.  If
>>we have 96 beans in the container everything works fine, but if we add
>>one more bean, say bean97, the container complains that there may be a
>>circular reference even though I'm sure there isn't. But if we remove a
>>different (and totally unrelated) bean and add our bean97 bean it works
>>fine.  It seems the container has a bean threshold of 96?!
>>
>>Basically, we cannot add any than 96 beans to the container.
>>
>>Have you seen this behaviour before?
>>
>>--
>>Cheers,
>>
>>Ross
>>http://blog.rossmason.com
>>    
>>

Re: [Springframework-developer] Container Bean threshold?

[Mike Cannon-B. <mi...@at...>]

Obviously this is a big problem to us right now (doh), as Confluence has
just passed 96 beans in Spring (yay!).

Charles and I have just been investigating in more detail, it seems that as
soon as we add the _97th_ bean, one of our _circular_ references barfs.

We'll investigate further - but any ideas as to where to look would be most
appreciated :)

Cheers,
Mike

PS It may also be some sort of a limit in the number of circular referenced
beans, or singletons? I'm not sure.

On 4/2/04 1:43 PM, "Ross Mason" (ro...@at...) penned the words:

> Hi guys,
> 
> I've just found some interesting behaviour in the spring container.  If
> we have 96 beans in the container everything works fine, but if we add
> one more bean, say bean97, the container complains that there may be a
> circular reference even though I'm sure there isn't. But if we remove a
> different (and totally unrelated) bean and add our bean97 bean it works
> fine.  It seems the container has a bean threshold of 96?!
> 
> Basically, we cannot add any than 96 beans to the container.
> 
> Have you seen this behaviour before?
> 
> --
> Cheers,
> 
> Ross
> http://blog.rossmason.com
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Container Bean threshold?

[Ross M. <ro...@at...>]

Hi guys,

I've just found some interesting behaviour in the spring container.  If 
we have 96 beans in the container everything works fine, but if we add 
one more bean, say bean97, the container complains that there may be a 
circular reference even though I'm sure there isn't. But if we remove a 
different (and totally unrelated) bean and add our bean97 bean it works 
fine.  It seems the container has a bean threshold of 96?!

Basically, we cannot add any than 96 beans to the container.

Have you seen this behaviour before?

--
Cheers,

Ross
http://blog.rossmason.com

Re: [Springframework-developer] NestedRuntimeException

[<jue...@we...>]

Don't bother, I've already changed that yesterday :-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Di 03.02.2004 05:36
An: spr...@li...
Betreff: Re: [Springframework-developer] NestedRuntimeException



Oliver Hutchison wrote:

>I'm currently writing a simple little query system which will some =
times
>execute queries using the JdbcTemplate but also some times need to do
>direct execution using JDBC.
>
>It the part of this code that is responsible for catching exceptions =
and
>giving the user appropriate error messages I have had to write two sets
>of code to find the root cause of exceptions as the
>NestedRuntimeException in Spring has it's getRootCause method and most
>of the other exception I encounter use getCause.
>
>I think it would be great if Spring also supported the Java 1.4 style
>getCause method. Why not just override the getCause method with a call
>to getRootCause? Or if you didn't want to do that this could be added
>quite easily using reflection. Something like this in the constructor
>should do the trick:
>      =20
>        try {
>            this.getClass().getMethod("initCause", new Class[]
>{Throwable.class})
>                .invoke(this, new Object[] {e});
>        } catch(Exception ex) {
>            // guess it's not 1.4+   =20
>         }
>
>
>Ollie
>=20
>
Coincidentally, we had a bit of a discussion about this w/regards to
NestedCheckedException, just a couple of days ago.

I should be able to find time tomorrow to to change
NestedCheckedException and NestedRuntimeException in this fashion...




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] NestedRuntimeException

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

Oliver Hutchison wrote:

>I'm currently writing a simple little query system which will some times
>execute queries using the JdbcTemplate but also some times need to do
>direct execution using JDBC.
>
>It the part of this code that is responsible for catching exceptions and
>giving the user appropriate error messages I have had to write two sets
>of code to find the root cause of exceptions as the
>NestedRuntimeException in Spring has it's getRootCause method and most
>of the other exception I encounter use getCause.
>
>I think it would be great if Spring also supported the Java 1.4 style
>getCause method. Why not just override the getCause method with a call
>to getRootCause? Or if you didn't want to do that this could be added
>quite easily using reflection. Something like this in the constructor
>should do the trick:
>        
>        try {
>            this.getClass().getMethod("initCause", new Class[]
>{Throwable.class})
>                .invoke(this, new Object[] {e});
>        } catch(Exception ex) {
>            // guess it's not 1.4+     
>   	  }
>
>
>Ollie
>  
>
Coincidentally, we had a bit of a discussion about this w/regards to 
NestedCheckedException, just a couple of days ago.

I should be able to find time tomorrow to to change 
NestedCheckedException and NestedRuntimeException in this fashion...

[Springframework-developer] NestedRuntimeException

[Oliver H. <Oli...@ou...>]

I'm currently writing a simple little query system which will some times
execute queries using the JdbcTemplate but also some times need to do
direct execution using JDBC.

It the part of this code that is responsible for catching exceptions and
giving the user appropriate error messages I have had to write two sets
of code to find the root cause of exceptions as the
NestedRuntimeException in Spring has it's getRootCause method and most
of the other exception I encounter use getCause.

I think it would be great if Spring also supported the Java 1.4 style
getCause method. Why not just override the getCause method with a call
to getRootCause? Or if you didn't want to do that this could be added
quite easily using reflection. Something like this in the constructor
should do the trick:
       =20
        try {
            this.getClass().getMethod("initCause", new Class[]
{Throwable.class})
                .invoke(this, new Object[] {e});
        } catch(Exception ex) {
            // guess it's not 1.4+    =20
   	  }


Ollie

RE: [Springframework-developer] Documentation mistake

[Alef A. <al...@jt...>]

Thanks Les,

I've updated it in the CVS (not yet published on the website though).

Alef

> -----Original Message-----
> From: spr...@li... 
> [mailto:spr...@li...]
>  On Behalf Of Les A. Hazlewood
> Sent: Sunday, February 01, 2004 7:20 PM
> To: spr...@li...
> Subject: [Springframework-developer] Documentation mistake
> 
> 
> Just browsing the new docs:
> 
> In section 4.3.2, the code example shows how to register a 
> custom property editor.  Going off of the 1.0 M4 API, The 
> example should list:
> 
> beanFactory.registerCustomEditor(Date.class, new CustomDateEditor());
> 
> instead of
> 
> beanFactory.registerCustomEditor(Date.class, CustomDateEditor.class);
> 
> Just passing along...
> 
> Regards,
> 
> Les
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration 
> See the breadth of Eclipse activity. February 3-5 in Anaheim, 
> CA. http://www.eclipsecon.org/osdn 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] Re: Proxying target classes

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

Chris Nokleberg wrote:

>Colin Sampaleanu wrote:
>  
>
>>The class is not final, and there are no final methods. And I was wrong,
>>it actually already implemented one interface, InitializingBean.
>>    
>>
>
>I sent a reply before but it didn't show up. I'm pretty sure this is a bug
>that was fixed recently in CGLIB CVS. If you could try with a newer jar
>file I would appreciate it, otherwise let me know how to reproduce the
>problem.
>
>Thanks,
>Chris
>
>  
>
Chris/Rod,

I found some time just now to temporarilly back out my changes, and try 
the previous problem code with the cglib from CVS (as of yesterday), and 
indeed that version appears to resolve the problem discussed in this thread.

Rod, I'm not clear on how general a bug/problem this is in cglib (ie 
will it affect only some uses of targetProxyClass=true, or only some?), 
but does it warrant shipping a CVS version of cglib with the upcoming 
1.0RC1 version?

Regards,
Colin

Re: [Springframework-developer] reference docs

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

Darren Davison wrote:

>On Sunday 01 February 2004 17:09, Alef Arendsen wrote:
>  
>
>>About the Tiles stuff, the documentation on the website describes things
>>pretty well, however, it's not complete (ComponentControllerSupport
>>explanation is missing I believe). But if you can include it as it is
>>right now, that would be great!
>>    
>>
>
>ok, I'll add Tiles info (and Tapestry unless Colin would prefer to - let me 
>know?).  May aswell do PDF/Excel while I'm at it, I've got a project coming 
>up that will require dynamic PDF generation so it'll be handy!
>  
>
If you can spare the time to do something based on my article, that 
would be great. I've been meanting to for a while, but the reality is I 
will be way overloaded with work related activing until about mid-March. 
I can certainly go over it to verify that it makes sense, and add any 
needed changes...

Regards,
Colin

Re: [Springframework-developer] reference docs

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

On Sunday 01 February 2004 17:09, Alef Arendsen wrote:
> About the Tiles stuff, the documentation on the website describes things
> pretty well, however, it's not complete (ComponentControllerSupport
> explanation is missing I believe). But if you can include it as it is
> right now, that would be great!

ok, I'll add Tiles info (and Tapestry unless Colin would prefer to - let me 
know?).  May aswell do PDF/Excel while I'm at it, I've got a project coming 
up that will require dynamic PDF generation so it'll be handy!

-- 

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

[Springframework-developer] Documentation mistake

[Les A. H. <le...@ha...>]

Just browsing the new docs:

In section 4.3.2, the code example shows how to register a custom property
editor.  Going off of the 1.0 M4 API, The example should list:

beanFactory.registerCustomEditor(Date.class, new CustomDateEditor());

instead of

beanFactory.registerCustomEditor(Date.class, CustomDateEditor.class);

Just passing along...

Regards,

Les

Re: [Springframework-developer] new controller type

[Luke T. <ne...@fr...>]

Ronald Haring wrote:
> Ah ok, thx for the info.
> 
> As said on the download and credits page (but unfortunately you couldnt 
> read that) I am only a simple programmer and the css came from a css 
> site. I will change the style sheet to a simpler design.
> 

I don't think there's anything wrong with the articles from "A List 
Apart" - those
guys are pretty much on the ball as far as browser issues go and the 
examples from there
are OK in Mozilla - likewise with struts-menu which also uses the 
"sliding doors" css tabs.

Luke.

-- 
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk

RE: [Springframework-developer] reference docs

[Alef A. <al...@jt...>]

> I've updated the reference docs for Velocity and XSLT 
> integration.  Within 
> the views.xml file are placeholders for Tiles and Tapestry 
> too since this 
> info sits quite well in there.
I saw that, great!

I just updated the docs on the website, including my latest changes.
I've been moving some pieces around a bit, including the PropertyEditor
and BeanWrapper stuff, that now has got its place in the
Validation/PropertyEditors/BeanWrapper/DataBinder chapter. Not
completely finished though, so read it at your own risk ;-).

> Unfortunately, I'm not at all familiar with Tapestry and have 
> only really 
> toyed with Tiles.  However, if no-one else has time to do it, 
> I'm happy to 
> hack out the reference docs for them based on Alef's tiles-sample 
> application and Colin's Tapestry html document.  As long as 
> someone checks 
> them afterwards for erroneous assumptions or blatent errors, 
> it should be 
> ok.
Unfortunately I don't have too much experience with Tapestry as well.
About the Tiles stuff, the documentation on the website describes things
pretty well, however, it's not complete (ComponentControllerSupport
explanation is missing I believe). But if you can include it as it is
right now, that would be great!

I hope to get some more work done on the Context and Beans package
coming week. Also, I was planning to integrate documetnation generation
with the Maven build, but haven't got to that yet.

Thomas, I've added links to both HTML and PDF (which by the way is about
100 pages already) documentation now on the website and including a CSS
in the docs/styles directory (I'll change the DocBook XSL some time soon
so we'll be able to move the stylesheet to the reference/styles
directory). Just to let you know.

Alef

[Springframework-developer] Maven / Ibiblio

[Alef A. <al...@jt...>]

A request has been done to upload spring-1.0m4 to ibiblio. We'll just
have to wait for the Maven guys to get that done.

Regards,
Alef

[Springframework-developer] reference docs

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

I've updated the reference docs for Velocity and XSLT integration.  Within 
the views.xml file are placeholders for Tiles and Tapestry too since this 
info sits quite well in there.

Unfortunately, I'm not at all familiar with Tapestry and have only really 
toyed with Tiles.  However, if no-one else has time to do it, I'm happy to 
hack out the reference docs for them based on Alef's tiles-sample 
application and Colin's Tapestry html document.  As long as someone checks 
them afterwards for erroneous assumptions or blatent errors, it should be 
ok.

Cheers,
-- 

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

[Springframework-developer] Re: [Springframework-user] service locator via static accessors

[Keith D. <kd...@cs...>]

Colin,

Yea, I spent some time digesting that article yesterday.  I posted a summary
of what I learned on my blog at http://www.jroller.com/page/kdonald.  I
actually evaluated HiveMind before I got into the details of Eclipse plugin
model--now that I've done that, HiveMind makes a lot more sense. :-)

I too am interested in seeing how Spring and the Eclipse plugin model can be
integrated with rich-client apps built on the Eclipse platform as 3.0
matures.  I'm also interesting in seeing how this this OSGi standard
(Equinox stuff) is going to effect the current architecture

Keith


----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: "Keith Donald" <kd...@cs...>
Cc: <spr...@li...>
Sent: Saturday, January 31, 2004 11:10 PM
Subject: Re: [Springframework-user] service locator via static accessors


> Keith,
>
> That's actually an excellent article about the Eclipse plugin model.
> I've always been impressed with the Eclipse model; I think (especially
> with the dynamic loading and unloading work they're doing for 3.0), that
> it's a well thought out and usable architecture. While there is some
> overlap between the Eclipse plugin model and Spring, they would also be
> complimentary to each other. I think the strength in the Eclipse model
> is it's strong lifecycle support, the isolation it can ensure for
> different code, and its suitability in general for component oriented
> programming, with things like the extension points. Where Spring is very
> strong is in its ease of use and simplicity (I do think Spring is simple
> to use, despite all its features, most of which are orthogonal in nature
> to the core container), and of course the incredibly rich support
> library built around the core, such as the tx and db related
> functionality. As the Eclipse 3.0 stream continues to develop I am going
> to spend more time trying to figure out how Spring fits in that
> environment. Another related project worth keeping an eye on is Howard
> Lewis Ship's HiveMind projects, which is essentially based on the
> Eclipse plugin model, but using some aspects (no pun intended) found in
> Spring, such as the use of interceptors and other bytecode modification.
>
> Regards,
> Colin
>
>
> Keith Donald wrote:
>
> >Colin,
> >
> >Have you seen this article on the Eclipse plugin model/architecture?
>
>http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_archite
cture.html
> >
> >It was a pretty good read.
> >
> >As you probably already know, some of the features provided are similiar
to
> >Spring's microkernel!  A plugin extension point is essentially a
definition
> >of a service interface, and each extension (implementation) is capable of
> >being parameterized (using a very xml-like approach.)  And then there is
a
> >controlling "host plugin" which manages plugging in the extensions,
> >lazy-loading by creating proxies, and invoking an extension's
implementation
> >using callback interfaces or observer-type notifications.  The
> >PluginRegistry is esponsible for loading the individual plugin
definitions
> >at runtime using their own classloader, and their is a mechanism for how
> >different plugins can use each other (though I'm not real clear on that.)
> >
> >What features in the Eclipse model do you think would be useful in
Spring?
> >A way to package a spring bean factory as some kind of plugin that can be
> >loaded on demand?
> >
> >I didn't post this to the list b/c it was a little off-topic, but if you
> >think it's relavent, feel free to post it or your response or whatever.
> >Keith
> >
> >----- Original Message ----- 
> >From: "Colin Sampaleanu" <col...@ex...>
> >To: <spr...@li...>
> >Sent: Friday, January 30, 2004 11:13 PM
> >Subject: Re: [Springframework-user] service locator via static accessors
> >
> >
> >
> >
> >>I'm a fan of maintaining inversion of control if at all possible, so on
> >>that basis, for your scenario, at least to some extent, using either
> >>your solution or the ContextLocator impl. I mentioned has a bit of a bad
> >>smell about it.
> >>
> >>Ultimately, it comes down to how well you can isolate your code from
> >>other code, and how well you can test it. For testing you can presumably
> >>still set up a test context (which creates the singleton instance of
> >>your locator with test objects), and then start using the objects in a
> >>test mode. You do have the limitation that there is that one instance
> >>which all the objects running during the test will have to share, so
> >>depending on the complexity of the test that may or may not be an issue.
> >>For a unit test it would probably not be an issue.
> >>
> >>In terms of coupling, the locator couples classes together to some
> >>extent if it has hard class/interface names in its method signatures,
> >>but adding one or moving one would not break binary compatibility of
> >>code not using those methods.
> >>
> >>At the end of the day, most of the time, I would personally do the extra
> >>work and go for real IOC, except for the small bits of non IOC glue code
> >>that is sometimes needed to kick off the rest of the code in an IOC
> >>fashion. I think if you're careful you can write pretty good code even
> >>using something like a 'global' locator like this, but temptation to do
> >>bad things (break the Law of Demeter and other assorted nasties) will be
> >>much greater.
> >>
> >>(Where this discussion gets more interesting is when you are running in
> >>an environment like the Eclipse plugin model, which through its multiple
> >>classloaders for plugins, extension-points, extensions, and plugin
> >>lifecycles, is essentially like a locator/registry which doesn't let you
> >>do some of the things you really shouldn't be doing. Unfortunately at
> >>this point, Spring doesn't offer much in that respect.)
> >>
> >>
> >>Keith Donald wrote:
> >>
> >>
> >>
> >>>Colin,
> >>>
> >>>I imagine you saw the simple BeanFactoryPostProcessor solution I
posted.
> >>>
> >>>
> >It
> >
> >
> >>>seems to work well and keeps me from being dependent on any Spring
> >>>
> >>>
> >APIs -- 
> >
> >
> >>>the locator and the services it provides access to are simply loaded by
a
> >>>"ServiceLocatorLoader" factory post-processor before any other beans
are
> >>>created in the factory.  I find this solution more attractive than
making
> >>>
> >>>
> >my
> >
> >
> >>>objects that require these services use the ApplicationContext as a
> >>>
> >>>
> >locator
> >
> >
> >>>(which is less typesafe and is a Spring class), or having to inject my
> >>>
> >>>
> >own
> >
> >
> >>>locator on each instance (where again, I have many instance, and not
all
> >>>
> >>>
> >are
> >
> >
> >>>instantiated by the container - some programatically..which for my less
> >>>experience developers I've found can lead to confusion and bugs
> >>>
> >>>
> >(especially
> >
> >
> >>>with setter-injection)....)
> >>>
> >>>So with that said, do you still not like what I'm doing?  The only
extra
> >>>dependency I have is on my service locator class itself because of the
> >>>
> >>>
> >one
> >
> >
> >>>static call.  The other dependencies (the located service interfaces) I
> >>>would have regardless of whether I used the ServiceLocator pattern or
> >>>Dependency Injection.  It seems like a very small price to pay, if any
> >>>(maybe I am missing something?)
> >>>
> >>>Keith
> >>>
> >>>----- Original Message ----- 
> >>>From: "Colin Sampaleanu" <col...@ex...>
> >>>To: <spr...@li...>
> >>>Sent: Wednesday, January 28, 2004 2:39 PM
> >>>Subject: Re: [Springframework-user] service locator via static
accessors
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>Keith,
> >>>>
> >>>>Take a look at the BeanFactoryLocator interface I checked in a few
days
> >>>>ago (message describing it was in the dev mailing list), and the hard
> >>>>implementations, SimpleBeanFactoryLocator and
DefaultBeanFactoryLocator,
> >>>>which are keyed-singletons.
> >>>>
> >>>>Personally, in your situation I would do the grunt work for most of
the
> >>>>code to not use any sort of singleton, but the above classes would
> >>>>certainly allow you to do something like:
> >>>>
> >>>>BeanFactoryLocator bfl = LocatorFactory.getInstance();
> >>>>BeanFactory bf = bfl.useFactory("some key to a context, which can also
> >>>>be an alias").getFactory();
> >>>>// now use the BeanFactory as a service locator object
> >>>>MyService myService = (MyService) bf.getBean("myservice");
> >>>>
> >>>>Again, I would stay away from this type of code. These
> >>>>BeanFactoryLocator implementations were more meant for usage in
> >>>>scenarios when you have no other choice at all, e.g. third party code
> >>>>does a Class.forName() call, so you have no other way to get something
> >>>>out of a context. Another usage scenario is demand loading of context,
> >>>>as done by glue code between layers.
> >>>>
> >>>>In your example, you're doing it to save a bit of effort in organizing
> >>>>your classes so everything comes out of the context in IOC fashion,
but
> >>>>you're paying for it because you then have some unnecessary coupling
to
> >>>>Spring.
> >>>>
> >>>>At a minimum, if you were to use these classes in all your code, I
would
> >>>>try to make it easier to unit test stuff by providing a setter for the
> >>>>BeanFactory, and then only looking it up if it's not set. That way,
for
> >>>>a unit test, you would set the servicelocator beanfactory directly,
> >>>>instead of letting the code look it up through the singleton.
> >>>>
> >>>>Regards,
> >>>>Colin
> >>>>
> >>>>
> >>>>Keith Donald wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Hey yall,
> >>>>>
> >>>>>I have a question about the use of statics within Spring, particulary
> >>>>>static access to a service locator configured by Spring.  (I know
> >>>>>statics are frowned upon :(, but in my case it makes sense.)
> >>>>>
> >>>>>What's the best way to ensure a statically-accessed service locator
> >>>>>and its dependencies are instantiated before the rest of the objects
> >>>>>in the system?  I thought about the "bean dependsOn" option, but I
> >>>>>have lots of beans, so that seems tedius & error prone.  I could
> >>>>>create a separate "startup" context and load my locator there first,
> >>>>>but I'd like all the beans reachable through one master context if
> >>>>>possible.  Is it possible to use a BeanFactoryPostProcessor
> >>>>>to instantiate the locator first?  Are there any other ways you guys
> >>>>>would recommend?
> >>>>>
> >>>>>Here's a little more background on what I'm doing: I have several
> >>>>>different services most all of my application objects require -- 
> >>>>>messages, iconLoading, actionRegistration, imageLoading/Caching, and
> >>>>>in my system there are lots of little objects running around that
need
> >>>>>these services -- hence having to inject these common dependencies on
> >>>>>every single object is tedius.  If I use setter-injection, I might
> >>>>>forget to configure a object (especially if I need to instantiate
> >>>>>programatically, which sometimes I do.)  If I use constructor
> >>>>>injection, I've got that ServiceLocator as a argument to almost every
> >>>>>constructor, which just seems unnatural.  So the simple compromise is
> >>>>>a static lookup mechanism to a ServiceLocator
> >>>>>instance that retrieves interfaces for each of my services.  The
> >>>>>locator itself is configured by Spring, as are the service instances,
> >>>>>so I don't lose any pluggability, the only trick is I've got to
ensure
> >>>>>the Locator is initialized/configured first.  I need to understand
the
> >>>>>best way to handle that case.
> >>>>>
> >>>>>Thanks!
> >>>>>Keith
> >>>>>
> >>>>>Keith Donald
> >>>>>Senior Software Engineer
> >>>>>*kd...@cs... <mailto:kd...@cs...>*
> >>>>>
> >>>>>
> >>>>>
> >>>>>
>

Re: [Springframework-developer] new controller type

[Ronald H. <ro...@co...>]

Ah ok, thx for the info.

As said on the download and credits page (but unfortunately you couldnt 
read that) I am only a simple programmer and the css came from a css 
site. I will change the style sheet to a simpler design.

Gr
Ronald

William G. Thompson, Jr wrote:

> same goes for Firebird
>
> John K.Watson wrote:
>
>> Your css is quite broken in Safari, btw.  The page contents are all 
>> off screen...
>>     John
>>
>> On Jan 30, 2004, at 3:56 AM, Ronald Haring wrote:
>>
>>> Hello all,
>>>
>>> last months I have been looking around in the springframework, and I
>>> really liked what I saw. So I thought to merge my own workflow 
>>> system with
>>> the spring framework. After some time of working on it, it is now
>>> available as open source for all of you to enjoy.
>>>
>>> The main features of the workflow system that I have made is the
>>> navigation aspect on the html level. Many jsp pages have a common 
>>> menu to
>>> navigate the site. To show all the correct menu items on a page, you 
>>> have
>>> to be aware of the page you are working on and update the menu on each
>>> page. With the workflow system that I have made up, you only have to 
>>> have
>>> one include.jsp with all of the navigation actions that are allowed. 
>>> Based
>>> on the settings of an configuration xml file, the system will determine
>>> which actions should be available to users and which not. This is also
>>> dependant on the role of a logged in user. Also with the workflow 
>>> system,
>>> you can stack multiple controllers and let them perform their methods
>>> before returning a page.
>>>
>>> The website is available at www.competities.com/springworkflow and in
>>> sourceforge.net you can download the cvs sources. The sources come 
>>> with a
>>> demo rss reader in which all the aspects of the workflow system are
>>> (hopefully) demonstrated.
>>>
>>> Hopefully this is interesting enough for other people and maybe even
>>> usefull enought to get incorporated into the main spring mvc system.
>>>
>>> Gr
>>> Ronald
>>>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: [Springframework-user] service locator via static accessors

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

Keith,

That's actually an excellent article about the Eclipse plugin model. 
I've always been impressed with the Eclipse model; I think (especially 
with the dynamic loading and unloading work they're doing for 3.0), that 
it's a well thought out and usable architecture. While there is some 
overlap between the Eclipse plugin model and Spring, they would also be 
complimentary to each other. I think the strength in the Eclipse model 
is it's strong lifecycle support, the isolation it can ensure for 
different code, and its suitability in general for component oriented 
programming, with things like the extension points. Where Spring is very 
strong is in its ease of use and simplicity (I do think Spring is simple 
to use, despite all its features, most of which are orthogonal in nature 
to the core container), and of course the incredibly rich support 
library built around the core, such as the tx and db related 
functionality. As the Eclipse 3.0 stream continues to develop I am going 
to spend more time trying to figure out how Spring fits in that 
environment. Another related project worth keeping an eye on is Howard 
Lewis Ship's HiveMind projects, which is essentially based on the 
Eclipse plugin model, but using some aspects (no pun intended) found in 
Spring, such as the use of interceptors and other bytecode modification.

Regards,
Colin


Keith Donald wrote:

>Colin,
>
>Have you seen this article on the Eclipse plugin model/architecture?
>http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html
>
>It was a pretty good read.
>
>As you probably already know, some of the features provided are similiar to
>Spring's microkernel!  A plugin extension point is essentially a definition
>of a service interface, and each extension (implementation) is capable of
>being parameterized (using a very xml-like approach.)  And then there is a
>controlling "host plugin" which manages plugging in the extensions,
>lazy-loading by creating proxies, and invoking an extension's implementation
>using callback interfaces or observer-type notifications.  The
>PluginRegistry is esponsible for loading the individual plugin definitions
>at runtime using their own classloader, and their is a mechanism for how
>different plugins can use each other (though I'm not real clear on that.)
>
>What features in the Eclipse model do you think would be useful in Spring?
>A way to package a spring bean factory as some kind of plugin that can be
>loaded on demand?
>
>I didn't post this to the list b/c it was a little off-topic, but if you
>think it's relavent, feel free to post it or your response or whatever.
>Keith
>
>----- Original Message ----- 
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Friday, January 30, 2004 11:13 PM
>Subject: Re: [Springframework-user] service locator via static accessors
>
>
>  
>
>>I'm a fan of maintaining inversion of control if at all possible, so on
>>that basis, for your scenario, at least to some extent, using either
>>your solution or the ContextLocator impl. I mentioned has a bit of a bad
>>smell about it.
>>
>>Ultimately, it comes down to how well you can isolate your code from
>>other code, and how well you can test it. For testing you can presumably
>>still set up a test context (which creates the singleton instance of
>>your locator with test objects), and then start using the objects in a
>>test mode. You do have the limitation that there is that one instance
>>which all the objects running during the test will have to share, so
>>depending on the complexity of the test that may or may not be an issue.
>>For a unit test it would probably not be an issue.
>>
>>In terms of coupling, the locator couples classes together to some
>>extent if it has hard class/interface names in its method signatures,
>>but adding one or moving one would not break binary compatibility of
>>code not using those methods.
>>
>>At the end of the day, most of the time, I would personally do the extra
>>work and go for real IOC, except for the small bits of non IOC glue code
>>that is sometimes needed to kick off the rest of the code in an IOC
>>fashion. I think if you're careful you can write pretty good code even
>>using something like a 'global' locator like this, but temptation to do
>>bad things (break the Law of Demeter and other assorted nasties) will be
>>much greater.
>>
>>(Where this discussion gets more interesting is when you are running in
>>an environment like the Eclipse plugin model, which through its multiple
>>classloaders for plugins, extension-points, extensions, and plugin
>>lifecycles, is essentially like a locator/registry which doesn't let you
>>do some of the things you really shouldn't be doing. Unfortunately at
>>this point, Spring doesn't offer much in that respect.)
>>
>>
>>Keith Donald wrote:
>>
>>    
>>
>>>Colin,
>>>
>>>I imagine you saw the simple BeanFactoryPostProcessor solution I posted.
>>>      
>>>
>It
>  
>
>>>seems to work well and keeps me from being dependent on any Spring
>>>      
>>>
>APIs -- 
>  
>
>>>the locator and the services it provides access to are simply loaded by a
>>>"ServiceLocatorLoader" factory post-processor before any other beans are
>>>created in the factory.  I find this solution more attractive than making
>>>      
>>>
>my
>  
>
>>>objects that require these services use the ApplicationContext as a
>>>      
>>>
>locator
>  
>
>>>(which is less typesafe and is a Spring class), or having to inject my
>>>      
>>>
>own
>  
>
>>>locator on each instance (where again, I have many instance, and not all
>>>      
>>>
>are
>  
>
>>>instantiated by the container - some programatically..which for my less
>>>experience developers I've found can lead to confusion and bugs
>>>      
>>>
>(especially
>  
>
>>>with setter-injection)....)
>>>
>>>So with that said, do you still not like what I'm doing?  The only extra
>>>dependency I have is on my service locator class itself because of the
>>>      
>>>
>one
>  
>
>>>static call.  The other dependencies (the located service interfaces) I
>>>would have regardless of whether I used the ServiceLocator pattern or
>>>Dependency Injection.  It seems like a very small price to pay, if any
>>>(maybe I am missing something?)
>>>
>>>Keith
>>>
>>>----- Original Message ----- 
>>>From: "Colin Sampaleanu" <col...@ex...>
>>>To: <spr...@li...>
>>>Sent: Wednesday, January 28, 2004 2:39 PM
>>>Subject: Re: [Springframework-user] service locator via static accessors
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>Keith,
>>>>
>>>>Take a look at the BeanFactoryLocator interface I checked in a few days
>>>>ago (message describing it was in the dev mailing list), and the hard
>>>>implementations, SimpleBeanFactoryLocator and DefaultBeanFactoryLocator,
>>>>which are keyed-singletons.
>>>>
>>>>Personally, in your situation I would do the grunt work for most of the
>>>>code to not use any sort of singleton, but the above classes would
>>>>certainly allow you to do something like:
>>>>
>>>>BeanFactoryLocator bfl = LocatorFactory.getInstance();
>>>>BeanFactory bf = bfl.useFactory("some key to a context, which can also
>>>>be an alias").getFactory();
>>>>// now use the BeanFactory as a service locator object
>>>>MyService myService = (MyService) bf.getBean("myservice");
>>>>
>>>>Again, I would stay away from this type of code. These
>>>>BeanFactoryLocator implementations were more meant for usage in
>>>>scenarios when you have no other choice at all, e.g. third party code
>>>>does a Class.forName() call, so you have no other way to get something
>>>>out of a context. Another usage scenario is demand loading of context,
>>>>as done by glue code between layers.
>>>>
>>>>In your example, you're doing it to save a bit of effort in organizing
>>>>your classes so everything comes out of the context in IOC fashion, but
>>>>you're paying for it because you then have some unnecessary coupling to
>>>>Spring.
>>>>
>>>>At a minimum, if you were to use these classes in all your code, I would
>>>>try to make it easier to unit test stuff by providing a setter for the
>>>>BeanFactory, and then only looking it up if it's not set. That way, for
>>>>a unit test, you would set the servicelocator beanfactory directly,
>>>>instead of letting the code look it up through the singleton.
>>>>
>>>>Regards,
>>>>Colin
>>>>
>>>>
>>>>Keith Donald wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Hey yall,
>>>>>
>>>>>I have a question about the use of statics within Spring, particulary
>>>>>static access to a service locator configured by Spring.  (I know
>>>>>statics are frowned upon :(, but in my case it makes sense.)
>>>>>
>>>>>What's the best way to ensure a statically-accessed service locator
>>>>>and its dependencies are instantiated before the rest of the objects
>>>>>in the system?  I thought about the "bean dependsOn" option, but I
>>>>>have lots of beans, so that seems tedius & error prone.  I could
>>>>>create a separate "startup" context and load my locator there first,
>>>>>but I'd like all the beans reachable through one master context if
>>>>>possible.  Is it possible to use a BeanFactoryPostProcessor
>>>>>to instantiate the locator first?  Are there any other ways you guys
>>>>>would recommend?
>>>>>
>>>>>Here's a little more background on what I'm doing: I have several
>>>>>different services most all of my application objects require -- 
>>>>>messages, iconLoading, actionRegistration, imageLoading/Caching, and
>>>>>in my system there are lots of little objects running around that need
>>>>>these services -- hence having to inject these common dependencies on
>>>>>every single object is tedius.  If I use setter-injection, I might
>>>>>forget to configure a object (especially if I need to instantiate
>>>>>programatically, which sometimes I do.)  If I use constructor
>>>>>injection, I've got that ServiceLocator as a argument to almost every
>>>>>constructor, which just seems unnatural.  So the simple compromise is
>>>>>a static lookup mechanism to a ServiceLocator
>>>>>instance that retrieves interfaces for each of my services.  The
>>>>>locator itself is configured by Spring, as are the service instances,
>>>>>so I don't lose any pluggability, the only trick is I've got to ensure
>>>>>the Locator is initialized/configured first.  I need to understand the
>>>>>best way to handle that case.
>>>>>
>>>>>Thanks!
>>>>>Keith
>>>>>
>>>>>Keith Donald
>>>>>Senior Software Engineer
>>>>>*kd...@cs... <mailto:kd...@cs...>*
>>>>>
>>>>>
>>>>>          
>>>>>

Re: [Springframework-developer] new controller type

[William G. T. J. <wg...@ru...>]

same goes for Firebird

John K.Watson wrote:
> Your css is quite broken in Safari, btw.  The page contents are all off 
> screen...
>     John
> 
> On Jan 30, 2004, at 3:56 AM, Ronald Haring wrote:
> 
>> Hello all,
>>
>> last months I have been looking around in the springframework, and I
>> really liked what I saw. So I thought to merge my own workflow system 
>> with
>> the spring framework. After some time of working on it, it is now
>> available as open source for all of you to enjoy.
>>
>> The main features of the workflow system that I have made is the
>> navigation aspect on the html level. Many jsp pages have a common menu to
>> navigate the site. To show all the correct menu items on a page, you have
>> to be aware of the page you are working on and update the menu on each
>> page. With the workflow system that I have made up, you only have to have
>> one include.jsp with all of the navigation actions that are allowed. 
>> Based
>> on the settings of an configuration xml file, the system will determine
>> which actions should be available to users and which not. This is also
>> dependant on the role of a logged in user. Also with the workflow system,
>> you can stack multiple controllers and let them perform their methods
>> before returning a page.
>>
>> The website is available at www.competities.com/springworkflow and in
>> sourceforge.net you can download the cvs sources. The sources come with a
>> demo rss reader in which all the aspects of the workflow system are
>> (hopefully) demonstrated.
>>
>> Hopefully this is interesting enough for other people and maybe even
>> usefull enought to get incorporated into the main spring mvc system.
>>
>> Gr
>> Ronald
>>

Re: [Springframework-developer] Re: Proxying target classes

[Les A. H. <le...@ha...>]

> >>>The class is not final, and there are no final methods. And I was wrong,
> >>>it actually already implemented one interface, InitializingBean.
> >>>
> >>>
> >>I sent a reply before but it didn't show up. I'm pretty sure this is a bug
> >>that was fixed recently in CGLIB CVS. If you could try with a newer jar
> >>file I would appreciate it, otherwise let me know how to reproduce the
> >>problem.
> >>
> >>
> >
> >As I've missed the beginning of this thread, I apologize if what I'm about
> to
> >ask was the exact same question about Proxying via CGLIB ;)  If not, it
> still
> >is related.
> >
> >We recently came across an issue that might prevent us from using Spring
> >(because of CGLIB dependencies) in client-tier swing/webstart/applet
> >deployments.
> >
> >
> Just to clarify; if you are ok with proxying only by interfaces (the
> default for Spring, controlled by the 'proxyTargetClass' param on the
> proxy factory bean classes), then Spring actually does not have any
> cglib dependencies; it will use a standard J2SE proxy.
>
> Now if you do set that flag to true, then it will use cglib and you will
> have the issues you mention in your environment...
>
> Regards,
> Colin

Incredible.  It seems as if things are even remotely configurable, Spring can
handle it!  Fantastic work!

Thanks again,

Les

Re: [Springframework-developer] Re: Proxying target classes

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

Les A. Hazlewood wrote:

>>Colin Sampaleanu wrote:
>>    
>>
>>>The class is not final, and there are no final methods. And I was wrong,
>>>it actually already implemented one interface, InitializingBean.
>>>      
>>>
>>I sent a reply before but it didn't show up. I'm pretty sure this is a bug
>>that was fixed recently in CGLIB CVS. If you could try with a newer jar
>>file I would appreciate it, otherwise let me know how to reproduce the
>>problem.
>>    
>>
>
>As I've missed the beginning of this thread, I apologize if what I'm about to
>ask was the exact same question about Proxying via CGLIB ;)  If not, it still
>is related.
>
>We recently came across an issue that might prevent us from using Spring
>(because of CGLIB dependencies) in client-tier swing/webstart/applet
>deployments.
>  
>
Just to clarify; if you are ok with proxying only by interfaces (the 
default for Spring, controlled by the 'proxyTargetClass' param on the 
proxy factory bean classes), then Spring actually does not have any 
cglib dependencies; it will use a standard J2SE proxy.

Now if you do set that flag to true, then it will use cglib and you will 
have the issues you mention in your environment...

Regards,
Colin