springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Tests (groovy!)

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

> Darren,
>
> Are you modifying Spring's standard build process here? Will this make
> Spring's standard build depend on Groovy? I feel that this is not too
> appropriate given that we are about to release 1.1 RC1 within the next
> couple of days.

No it won't affect the build or make it depend on groovy.  What I've done
for now is to take a copy of build.xml (called groovy-build.xml) and adde=
d
the groovyc taskdef and task to the buildtests target in there while
experimenting with it.  In fact those are the only 2 changes required to
the build to enable the whole process - it's pretty seamless.  Nor have I
modified any of the existing test classes, rather I've duplicated two tes=
t
classes, so in the tree for those 2 files only, a corresponding
*Tests.groovy file exists alongside the *Tests.java file.

If you build with build.xml, nothing unusual happens - any .groovy files
in the tree are simply ignored by javac and junit.  If you specify
-buildfile groovy-build.xml then the groovyc task will compile *.groovy
files to standard *.class files just as the javac task handles *.java
files.  The two languages can be mixed and matched seamlessly as the
bytecode is standard.

Once people have had a look at it, if it's something we want to use as an
option then we'd modify the main build.xml as described - but that can be
whenever.  Of course at that point, any new tests written in groovy
*would* have a dependency on groovy.jar but this is no more onerous than
depending on any other jar.  See below..

> I certainly don't object to doing tests with Groovy, but remember that =
we
> ship our build file and all libraries that we depend on in the
> "-with-dependencies" download, so that people can build Spring themselv=
es
> respectively run the test suite themselves. For 1.1, they should be abl=
e
> to do this without Groovy, IMO.

that's no problem, they can do that.  The only dependencies when running
tests written with groovy are: groovy.jar, which will be in /lib/groovy
(it also contains the groovyc ant task) and asm.jar which we already
depend on anyway.  The junit side of things is completely unmodified sinc=
e
any tests written in groovy extend GroovyTest which in turn extends
junit.framework.TestCase somewhere along the line.

There's no requirement to install any of the groovy binaries or other bit=
s
and pieces you can download from them, even when writing and running
groovy based unit tests - it's all pure java and all invoked via ant.

If you're still not comfortable with it and want to hold off committing
for a while, that's no problem at all.  The _only_ impact it will have is
adding a couple of hundred KB to the size of the release zip in practice,
since it will just be "another jar file" and won't be implicated in
anything the users want to do with the tests.

> Sorry if I misunderstand something here...

not at all - just let me know if you'd still prefer me to hold off?

Best wishes,
--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm

Re: [Springframework-developer] Tests (groovy!)

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

Darren,
=20
Are you modifying Spring's standard build process here? Will this make =
Spring's standard build depend on Groovy? I feel that this is not too =
appropriate given that we are about to release 1.1 RC1 within the next =
couple of days.
=20
I certainly don't object to doing tests with Groovy, but remember that =
we ship our build file and all libraries that we depend on in the =
"-with-dependencies" download, so that people can build Spring =
themselves respectively run the test suite themselves. For 1.1, they =
should be able to do this without Groovy, IMO.
=20
Sorry if I misunderstand something here...
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Darren Davison
Gesendet: Do 22.07.2004 13:20
An: spr...@li...
Betreff: Re: [Springframework-developer] Tests (groovy!)




> None of this is committed yet - I'll do it tonight and try to knock up =
a
> page in confluence about it.

An "in progress" page is here:
http://opensource.atlassian.com/confluence/spring/display/DISC/Groovy


--
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Tests (groovy!)

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

> None of this is committed yet - I'll do it tonight and try to knock up =
a
> page in confluence about it.

An "in progress" page is here:
http://opensource.atlassian.com/confluence/spring/display/DISC/Groovy


--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm

[Springframework-developer] Lengthy article on Spring

[Rod J. <rod...@in...>]

http://javaboutique.internet.com/tutorials/spring_frame/

[Springframework-developer] Tests (groovy!)

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

> Rod Johnson wrote (in another thread):
>> Alef, Darren
>>
>> Do either of you have time to experiment with the Groovy option?
>>
>> I think this is a very good idea.

I've created some test cases in the main test tree (duplicates of one or
two of the java based ones just for comparison).  build.xml has been
modified to compile the *.groovy files into the same target location
(test-classes) too.  The groovy compiler creates native bytecode so
generated class files are interchangeable with java class files and the
two languages can easily be mixed.

For now, the groovyc task runs after the javac task in the buildtests
target, so any classes that are duplicated (ie a FooBarTest.java and a
FooBarTest.groovy file in the same package) will simply cause the
resultant class file generated by javac to be overwritten by the one
generated by groovyc.  Obviously this won't be normal - tests will be
written in one or the other - but applies where I've created a couple of
duplicates for source comparison.  JUnit simply sees the compiled classes
as it would ones created with Java.

<disclaimer> I'm a groovy noob - my source files will certainly be
improvable! </disclaimer>

IDE integration is another matter.  Individual tests can be run by settin=
g
up a java application run target in Eclipse using a groovy supplied
wrapper class that executes the tests but this is only useful for
developing the tests.  The JUnit integration reads the source directories
not the binary target directory to get a list of classes to run, so it
ignores *.groovy files in the test tree.  There may be a way to make the
JUnit integration read the output dir that I'm not aware of in which case
it would work after compilation.

Obviously there's the headache of not getting all the nice syntax
highlighting, code completion, auto-compilation warnings etc. (you forget
just how much Eclipse does for you!)  There is a groovy Eclipse plugin,
but I couldn't get it working with 3.0 final.  The groovy devs on their
IRC channel assured me a new one was imminent so this IDE support should
improve soon.  I don't know what integration is like for other IDE's.

None of this is committed yet - I'll do it tonight and try to knock up a
page in confluence about it.  Unfortunately the groovy web site
(groovy.codehaus.org) seems to be in a bit of a mess - broken Maven build
or something?  There's at least 2 versions of some of the pages (3 if you
count what looks like an attempt to migrate it all to confluence) so it's
tricky to navigate to or find the useful info.  Of course, it's still
pretty new stuff :)

The language looks ideal for scripting unit tests - it has JUnit support
built in.  Favourite construct so far;

void testFoo() {
  shouldFail( {bar.methodThatShouldThrowException()} )
}

which replaces;

void testFoo() {
  try {
    bar.methodThatShouldThrowException();
    fail();

  } catch (Exception e) {
    // expected
  }
}

Groovy!

(sorry.)

Collection handling, iteration, bean property setting and closures all
look like serious verbosity savers in unit tests.  Some things are no
easier or less verbose than the java equivalents (at least with my very
limited experience).

D.


--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm

[Springframework-developer] Copland, a Ruby IOC container

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

For for thought. Seems to be originally based on HiveMind, although 
there are a lot of Rubyisms in there. One hting I wish we had in Java is 
a decent YAML parser (available for most of the scripting languages like 
Ruby, Python, and Perl). Compare some of the Yaml deployment descriptors 
to what an equivalent XML would be:
  http://copland.rubyforge.org/

Re: [Springframework-developer] reference data support classes

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

Yes! This could probably be used for theming too, right?

Keith Donald wrote:

> I’ve recently committed a package to the sandbox providing support for 
> internationalized labels / reference data, similar to what Gavin 
> discussed in this TSS article here:
>
> http://www.theserverside.com/blogs/showblog.tss?id=HibernateInternational
>
> The code provides support for labels coded by string, character, or 
> integer, and employs a Resolver interface for retrieving 
> internationalized label instances by type, locale, and/or code. There 
> is also basic Hibernate support (e.g custom user types.)
>
> I actually had the support checked in quite before this article was 
> written, but upon stumbling across it today it seemed worth mentioning 
> to see if there is enough general interest to make something like this 
> part of the core (in general, it’s a relatively few number of 
> classes.) I currently use it within rich client to drive the display 
> of combo box drop downs (e.g values in a combo box can be real objects 
> with behavior and internationalized labels.)
>
> Currently the code is in the sandbox under the package: 
> org.springframework.enums ‘enums’ might not be the best name, but in a 
> sense that’s what these little objects are. “label” or “referencedata” 
> might be candidates for a better package name, perhaps under “ui” 
> instead of as top level package.
>
> Keith
>

[Springframework-developer] reference data support classes

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

I've recently committed a package to the sandbox providing support for
internationalized labels / reference data, similar to what Gavin discussed
in this TSS article here:

 

http://www.theserverside.com/blogs/showblog.tss?id=HibernateInternational

 

The code provides support for labels coded by string, character, or integer,
and employs a Resolver interface for retrieving internationalized label
instances by type, locale, and/or code.  There is also basic Hibernate
support (e.g custom user types.)

 

I actually had the support checked in quite before this article was written,
but upon stumbling across it today it seemed worth mentioning to see if
there is enough general interest to make something like this part of the
core (in general, it's a relatively few number of classes.)  I currently use
it within rich client to drive the display of combo box drop downs (e.g
values in a combo box can be real objects with behavior and
internationalized labels.)

 

Currently the code is in the sandbox under the package:
org.springframework.enums  'enums' might not be the best name, but in a
sense that's what these little objects are. "label" or "referencedata" might
be candidates for a better package name, perhaps under "ui" instead of as
top level package.

 

Keith

[Springframework-developer] spring build.59 Build Successful

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

<html><head>
<style>
.white { color:#FFFFFF }.index { background-color:#FFFFFF }.index-passed { =
color:#004400 }.index-failed { color:#FF0000; font-weight:bold }.index-head=
er { font-weight:bold }.link { font-family:arial,helvetica,sans-serif; font=
-size:10pt; color:#FFFFFF; text-decoration:none; }.tab-table { margin: 0em =
0em 0.5em 0em; }.tabs { font-family:arial,helvetica,sans-serif; font-size:8=
pt; color:#000000; font-weight:bold; padding: 0em 2em; background-color:#EE=
EEEE; }.tabs-link { color:#000000; text-decoration:none; }.tabs-link:visite=
d { color:#000000; text-decoration:none; }.tabs-selected { font-family:aria=
l,helvetica,sans-serif; font-size:8pt; color:#000000; font-weight:bold; pad=
ding: 0em 2em; }.tabs-selected { border: inset; }.header-title { font-famil=
y:arial,helvetica,sans-serif; font-size:12pt; color:#000000; font-weight:bo=
ld; }.header-label { font-weight:bold; }.header-data { font-family:arial,he=
lvetica,sans-serif; font-size:10pt; color:#000000; }.modifications-data { f=
ont-family:arial,helvetica,sans-serif; font-size:8pt; color:#000000; }.modi=
fications-sectionheader { background-color:#000066; font-family:arial,helve=
tica,sans-serif; font-size:10pt; color:#FFFFFF; }.modifications-oddrow { ba=
ckground-color:#CCCCCC }.modifications-evenrow { background-color:#FFFFCC }=
.changelists-oddrow { background-color:#CCCCCC }.changelists-evenrow { back=
ground-color:#FFFFCC }.changelists-file-spacer { background-color:#FFFFFF }=
.changelists-file-evenrow { background-color:#EEEEEE }.changelists-file-odd=
row { background-color:#FFFFEE }.changelists-file-header { background-color=
:#666666; font-family:arial,helvetica,sans-serif; font-size:8pt; color:#FFF=
FFF; }.compile-data { font-family:arial,helvetica,sans-serif; font-size:8pt=
; color:#000000; }.compile-error-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#FF0000; }.compile-warn-data { font-family:arial,=
helvetica,sans-serif; font-size:8pt; color:#CC9900; }.compile-sectionheader=
 { background-color:#000066; font-family:arial,helvetica,sans-serif; font-s=
ize:10pt; color:#FFFFFF; }.distributables-data { font-family:arial,helvetic=
a,sans-serif; font-size:8pt; color:#000000; }.distributables-sectionheader =
{ background-color:#000066; font-family:arial,helvetica,sans-serif; font-si=
ze:10pt; color:#FFFFFF; }.distributables-oddrow { background-color:#CCCCCC =
}.unittests-sectionheader { background-color:#000066; font-family:arial,hel=
vetica,sans-serif; font-size:10pt; color:#FFFFFF; }.unittests-oddrow { back=
ground-color:#CCCCCC }.unittests-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#000000; }.unittests-error { font-family:arial,he=
lvetica,sans-serif; font-size:8pt; color:#FF0000; }.checkstyle-oddrow { bac=
kground-color:#CCCCCC }.checkstyle-data { font-family:arial,helvetica,sans-=
serif; font-size:8pt; color:#000000; }.checkstyle-sectionheader { backgroun=
d-color:#000066; font-family:arial,helvetica,sans-serif; font-size:10pt; co=
lor:#FFFFFF; }
</style>
</head><body>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"header-title">BUILD COMPLETE&nbsp;-&nbsp;     =
               build.59</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build:&nbsp;</span>07/22/2004 00:15:44</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>13 minutes 21 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed:&nbsp;</span>07/21/2004 15:54:05</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try:&nbsp;</span>Initial JMX Sandbox Commit.Made a small change to ClassUti=
ls in main tree to get Class instance for all names including primitives.Ad=
ded JMX 1.2.1 RI to the lib directory.</td></tr></table><p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"/><p>
<p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"><tr><td class=
=3D"compile-sectionheader">                        &nbsp;Errors/Warnings: (=
6)                    </td></tr><tr><td><pre class=3D"compile-error-data">N=
ote: Some input files use or override a deprecated API.<br class=3D"none"/>=
Note: Recompile with -deprecation for details.Note: /jteam/build/checkout/s=
pring/spring/mock/org/springframework/mock/web/MockHttpSession.java uses or=
 overrides a deprecated API.<br class=3D"none"/>Note: Recompile with -depre=
cation for details.<br class=3D"none"/>Note: Some input files use or overri=
de a deprecated API.<br class=3D"none"/>Note: Recompile with -deprecation f=
or details.<br class=3D"none"/></pre></td></tr></table><p>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"unittests-sectionheader">       =
            &nbsp;Unit Tests: (1470)                </td></tr><tr><td><tabl=
e width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"c=
enter"><tr><td class=3D"unittests-data">                failure            =
</td><td width=3D"40%" class=3D"unittests-data">testHomePage</td><td width=
=3D"40%" class=3D"unittests-data">org.springframework.apptests.buildtest.Al=
lTests</td></tr></table></td></tr><tr></tr><tr><td colspan=3D"2">&nbsp;</td=
></tr><tr><td colspan=3D"4" class=3D"unittests-sectionheader">             =
       &nbsp;Unit Test Error Details:&nbsp;(1)                </td></tr><tr=
><td class=3D"unittests-data" colspan=3D"2">                Test:&nbsp;test=
HomePage</td></tr><tr><td class=3D"unittests-data" colspan=3D"2">          =
      Class:&nbsp;org.springframework.apptests.buildtest.AllTests</td></tr>=
<tr><td class=3D"unittests-data" colspan=3D"2">                Type: junit.=
framework.AssertionFailedError</td></tr><tr><td class=3D"unittests-data" co=
lspan=3D"2">                Message: Exception while testing URL http://loc=
alhost:13084/buildtest:java.io.IOException</td></tr><tr><td class=3D"unitte=
sts-error" colspan=3D"2"><pre>junit.framework.AssertionFailedError: Excepti=
on while testing URL http://localhost:13084/buildtest:java.io.IOException<b=
r>=09at org.springframework.apptests.buildtest.AllTests.testHomePage(Unknow=
n Source)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Meth=
od)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess=
orImpl.java:39)<br>=09at sun.reflect.DelegatingMethodAccessorImpl.invoke(De=
legatingMethodAccessorImpl.java:25)<br></pre></td></tr><tr><td colspan=3D"2=
">&nbsp;</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"modifications-sectionheader">   =
                 &nbsp;Modifications since last build:&nbsp;               =
     (5)                </td></tr><tr class=3D"modifications-evenrow"><td c=
lass=3D"modifications-data">modified</td><td class=3D"modifications-data">r=
obharrop</td><td class=3D"modifications-data">/.classpath</td><td class=3D"=
modifications-data">Initial JMX Sandbox Commit.Made a small change to Class=
Utils in main tree to get Class instance for all names including primitives=
.Added JMX 1.2.1 RI to the lib directory.</td></tr><tr class=3D"modificatio=
ns-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"modif=
ications-data">robharrop</td><td class=3D"modifications-data">/build.xml</t=
d><td class=3D"modifications-data">Initial JMX Sandbox Commit.Made a small =
change to ClassUtils in main tree to get Class instance for all names inclu=
ding primitives.Added JMX 1.2.1 RI to the lib directory.</td></tr><tr class=
=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td><t=
d class=3D"modifications-data">robharrop</td><td class=3D"modifications-dat=
a">/project.properties</td><td class=3D"modifications-data">Initial JMX San=
dbox Commit.Made a small change to ClassUtils in main tree to get Class ins=
tance for all names including primitives.Added JMX 1.2.1 RI to the lib dire=
ctory.</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modificatio=
ns-data">modified</td><td class=3D"modifications-data">robharrop</td><td cl=
ass=3D"modifications-data">src/org/springframework/util/ClassUtils.java</td=
><td class=3D"modifications-data">Initial JMX Sandbox Commit.Made a small c=
hange to ClassUtils in main tree to get Class instance for all names includ=
ing primitives.Added JMX 1.2.1 RI to the lib directory.</td></tr><tr class=
=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td><t=
d class=3D"modifications-data">davison</td><td class=3D"modifications-data"=
>/build.xml</td><td class=3D"modifications-data">add vm and ftl files to cl=
asses dir</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"distributables-sectionheader">                =
        &nbsp;Deployments by this build:&nbsp;(8)                    </td><=
/tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/checko=
ut/spring/spring/dist/spring.jar</td></tr><tr class=3D"distributables-oddro=
w"><td class=3D"distributables-data">Building war: /jteam/build/checkout/sp=
ring/spring/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr><td c=
lass=3D"distributables-data">Building war: /jteam/build/checkout/spring/spr=
ing/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr class=3D"dist=
ributables-oddrow"><td class=3D"distributables-data">Building war: /jteam/b=
uild/checkout/spring/spring/autobuilds/apps/buildtest/dist/buildtest.war</t=
d></tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/che=
ckout/spring/spring/autobuilds/apps/jpetstore/war/WEB-INF/lib/jpetstore.jar=
</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distributables-d=
ata">Building war: /jteam/build/checkout/spring/spring/autobuilds/apps/jpet=
store/dist/jpetstore.war</td></tr><tr><td class=3D"distributables-data">Bui=
lding jar: /jteam/build/checkout/spring/spring/autobuilds/apps/jpetstore/wa=
r/WEB-INF/lib/jpetstore.jar</td></tr><tr class=3D"distributables-oddrow"><t=
d class=3D"distributables-data">Building war: /jteam/build/checkout/spring/=
spring/autobuilds/apps/jpetstore/dist/jpetstore.war</td></tr></table>
</body></html>

RE: [Springframework-developer] JMX Support

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

Keith, 

 

That would be great, give me a headstart on that!

 

Rob

 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Keith Donald
Sent: 21 July 2004 16:01
To: spr...@li...
Subject: RE: [Springframework-developer] JMX Support

 

Rob,

 

Looking forward to trying this out and reviewing in detail-

 

I can commit some initial JSR160 support if you like, as well as support for
various JMX adaptors (e.g the HTML adaptor for managing mbeans using a html
interface); this should go hand in hand with a bean (likely a FactoryBean?)
to configure a MBeanServer definition in a spring context (your "MBeanServer
Hosting" item below.)

 

Keith

 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Rob Harrop
Sent: Wednesday, July 21, 2004 10:08 AM
To: spr...@li...
Subject: [Springframework-developer] JMX Support

 

All,

 

Initial JMX Support is in the Sandbox for everyone to try out.

 

The initial feature set that I have is:

 

JmxMBeanAdapter that will expose any of your Spring beans to a running
MBeanServer. Beans are exposed via a Map in applicationContext.xml.

 

The JmxMBeanAdapter class supports the notion of metadata assemblers,
invokers and naming strategies. 

 

The metadata assemblers control how the bean is exposed to the MBeanServer.
The default implementation uses reflection and will expose all declared
methods as operations and all declared properties as attributes. Also
included is source level metadata support so you can choose which
methods/properties to expose. This uses the Spring metadata abstraction so
any metadata mechanism should be possible, but of course only Commons
Attributes is supported.

 

The invokers control how the operations and attributes on the mbean are
accessed by the MBean server. The default implementation is reflection-based
and I have created a CGLIB implementation as well. JMX 1.2 states that
attributes can no longer be accessed using operation semantics, that is
invoke(), so the implementation explicitly forbids that.

 

Naming strategies control what ObjectName is given to the MBean. There are a
few implementations in there already, one that uses the key of the bean Map,
one that uses the hashCode and class name and one that allows for the Map
key to be mapped to an entry in a properties file. 

 

I have also started the basics of proxying for MBean resources with a simple
CGLIB implementation.

 

I have some basic tests in the sandbox as well which should give you a good
idea of how to get started with the classes.

 

The exception hierarchy isn't as nice as I would like but I can modify as I
go through and clean up the code.

 

My plans for the rest of the week are to add a metadata naming strategy to
read the ObjectName from source level attributes, finish the proxying
support including a JDK proxy and a FactoryBean and really improve the test
suite. My feeling is that the current feature set is pretty usable, I just
need to polish up the tests and documentation.

 

Beyond this I will be adding support for:

 

-          Constructors. I will take a good look at the how instancing
semantics fit between JMX and Spring at this point as well.

-          Notifications. Need to have a good think about this, but I will
start with attribute change notifications and then look at linking in with
the event model to publish JMX notifications.

-          MBean Server Hosting. I will create a simple bean to host an
MBeanServer so that your application doesn't need to create one manually

-          Manual MBean Support. I will add support to auto register any
manually created MBeans.

-          Additional Metadata Support. In this way you can specify your
management interface metadata in XML, DB etc

-          JSR Frenzy - There are a bunch of JSR's that are JMX related that
could potentially be integrated into Spring.

 

Rob

RE: [Springframework-developer] JMX Support

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

Rob,

 

Looking forward to trying this out and reviewing in detail-

 

I can commit some initial JSR160 support if you like, as well as support for
various JMX adaptors (e.g the HTML adaptor for managing mbeans using a html
interface); this should go hand in hand with a bean (likely a FactoryBean?)
to configure a MBeanServer definition in a spring context (your "MBeanServer
Hosting" item below.)

 

Keith

 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Rob Harrop
Sent: Wednesday, July 21, 2004 10:08 AM
To: spr...@li...
Subject: [Springframework-developer] JMX Support

 

All,

 

Initial JMX Support is in the Sandbox for everyone to try out.

 

The initial feature set that I have is:

 

JmxMBeanAdapter that will expose any of your Spring beans to a running
MBeanServer. Beans are exposed via a Map in applicationContext.xml.

 

The JmxMBeanAdapter class supports the notion of metadata assemblers,
invokers and naming strategies. 

 

The metadata assemblers control how the bean is exposed to the MBeanServer.
The default implementation uses reflection and will expose all declared
methods as operations and all declared properties as attributes. Also
included is source level metadata support so you can choose which
methods/properties to expose. This uses the Spring metadata abstraction so
any metadata mechanism should be possible, but of course only Commons
Attributes is supported.

 

The invokers control how the operations and attributes on the mbean are
accessed by the MBean server. The default implementation is reflection-based
and I have created a CGLIB implementation as well. JMX 1.2 states that
attributes can no longer be accessed using operation semantics, that is
invoke(), so the implementation explicitly forbids that.

 

Naming strategies control what ObjectName is given to the MBean. There are a
few implementations in there already, one that uses the key of the bean Map,
one that uses the hashCode and class name and one that allows for the Map
key to be mapped to an entry in a properties file. 

 

I have also started the basics of proxying for MBean resources with a simple
CGLIB implementation.

 

I have some basic tests in the sandbox as well which should give you a good
idea of how to get started with the classes.

 

The exception hierarchy isn't as nice as I would like but I can modify as I
go through and clean up the code.

 

My plans for the rest of the week are to add a metadata naming strategy to
read the ObjectName from source level attributes, finish the proxying
support including a JDK proxy and a FactoryBean and really improve the test
suite. My feeling is that the current feature set is pretty usable, I just
need to polish up the tests and documentation.

 

Beyond this I will be adding support for:

 

-          Constructors. I will take a good look at the how instancing
semantics fit between JMX and Spring at this point as well.

-          Notifications. Need to have a good think about this, but I will
start with attribute change notifications and then look at linking in with
the event model to publish JMX notifications.

-          MBean Server Hosting. I will create a simple bean to host an
MBeanServer so that your application doesn't need to create one manually

-          Manual MBean Support. I will add support to auto register any
manually created MBeans.

-          Additional Metadata Support. In this way you can specify your
management interface metadata in XML, DB etc

-          JSR Frenzy - There are a bunch of JSR's that are JMX related that
could potentially be integrated into Spring.

 

Rob

Re: [Springframework-developer] E-Mail Templating Support

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

Point taken that this isn't properly covered in the reference docs yet. =
Matt wrote an article about it a while ago, though:

http://www.theserverside.com/blogs/showblog.tss?id=3DSpringVelocityEmail

Being curious: Which publisher do you write your Spring book for? Any =
special focus?

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rob Harrop
Sent: Wednesday, July 21, 2004 3:34 PM
To: spr...@li...
Subject: RE: [Springframework-developer] E-Mail Templating Support


Okay, I see what you are saying. It does seem as though this can't be
improved that much. I think the issue here is that this approach needs =
to be
covered in the docs, or maybe a blog entry. I don't mind putting =
something
together - I will also add this to this my book...

... which leads me nicely on to asking if anyone in the team wants to do =
the
tech review on the Spring book that a colleague and I are in the process =
of
writing.

Rob

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: 21 July 2004 14:22
To: spr...@li...
Subject: Re: [Springframework-developer] E-Mail Templating Support

I'm by no means against making this even easier :-) I just don't see =
much
potential beyond what's already there, at least if just concerning mail =
body
text...

The current best practice is to use Spring's VelocityEngineFactoryBean =
to
set up a shared VelocityEngine instance, passing it to application =
objects
as bean reference into a setVelocityEngine setter. Those application =
objects
will also receive an instance of Spring's MailSender interface if they =
want
to send emails. Using VelocityEngineUtils is then very straightforward.

FreeMarker is similar: Use a FreeMarkerConfigurationFactoryBean to set =
up a
shared FreeMarker Configuration instance, for bean references. Use
FreeMarkerTemplateUtils' processTemplateIntoString to render the =
template
into a String, to be used as mail text again.

The nice thing here is that the mail support does not know anything =
about
templating; neither the other way round. To make them work in =
combination,
you just generate a String via templating and pass it into a mail =
message as
text. And the setting up of shared engine instances leverages Spring's
common IoC infrastructure, without special mechanisms.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rob Harrop
Sent: Wednesday, July 21, 2004 3:09 PM
To: spr...@li...
Subject: RE: [Springframework-developer] E-Mail Templating Support


Well that is easy, but you need to create and configure an instance of
VelocityEngine before you can use that, and that may lead to the bad
practice of creating and initializing a new instance once per message. =
It
would be a trivial job to abstract all this away, plus then we could add
support for other templating engines.

Rob

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: 21 July 2004 13:40
To: spr...@li...
Subject: Re: [Springframework-developer] E-Mail Templating Support

That's already pretty easy: You can generate the email text with the
"mergeTemplateIntoString" of Spring's VelocityTemplateUtils helper, and =
pass
the result String into SimpleMailMessage's or MimeMessageHelper's =
setText
methods. 1 line to render the template (passing in a model Map), 1 line =
to
use it as email text for a given message.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Wednesday, July 21, 2004 1:36 PM
To: spr...@li...
Subject: Re: [Springframework-developer] E-Mail Templating Support


It seems like a good number of the relatively complex j2ee apps=20
eventually end up rolling their own version of something like this (I=20
know we did at one of my last gigs, although that was before spring), so =

if you can come up with a decent abstraction this would be worthwhile.


Rob Harrop wrote:

> I have been thinking of adding templated e-mail support to the mail=20
> package in Spring. In this way you can create the body of the mail as=20
> a Velocity template, and have data passed into the mail at runtime to=20
> customize it. I need to think a little more about how this would be=20
> implemented but I think the idea is sound. What does everyone else =
think?
>
> =20
>
> Rob
>




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] JMX Support

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

All,

 

Initial JMX Support is in the Sandbox for everyone to try out.

 

The initial feature set that I have is:

 

JmxMBeanAdapter that will expose any of your Spring beans to a running
MBeanServer. Beans are exposed via a Map in applicationContext.xml.

 

The JmxMBeanAdapter class supports the notion of metadata assemblers,
invokers and naming strategies. 

 

The metadata assemblers control how the bean is exposed to the MBeanServer.
The default implementation uses reflection and will expose all declared
methods as operations and all declared properties as attributes. Also
included is source level metadata support so you can choose which
methods/properties to expose. This uses the Spring metadata abstraction so
any metadata mechanism should be possible, but of course only Commons
Attributes is supported.

 

The invokers control how the operations and attributes on the mbean are
accessed by the MBean server. The default implementation is reflection-based
and I have created a CGLIB implementation as well. JMX 1.2 states that
attributes can no longer be accessed using operation semantics, that is
invoke(), so the implementation explicitly forbids that.

 

Naming strategies control what ObjectName is given to the MBean. There are a
few implementations in there already, one that uses the key of the bean Map,
one that uses the hashCode and class name and one that allows for the Map
key to be mapped to an entry in a properties file. 

 

I have also started the basics of proxying for MBean resources with a simple
CGLIB implementation.

 

I have some basic tests in the sandbox as well which should give you a good
idea of how to get started with the classes.

 

The exception hierarchy isn't as nice as I would like but I can modify as I
go through and clean up the code.

 

My plans for the rest of the week are to add a metadata naming strategy to
read the ObjectName from source level attributes, finish the proxying
support including a JDK proxy and a FactoryBean and really improve the test
suite. My feeling is that the current feature set is pretty usable, I just
need to polish up the tests and documentation.

 

Beyond this I will be adding support for:

 

-          Constructors. I will take a good look at the how instancing
semantics fit between JMX and Spring at this point as well.

-          Notifications. Need to have a good think about this, but I will
start with attribute change notifications and then look at linking in with
the event model to publish JMX notifications.

-          MBean Server Hosting. I will create a simple bean to host an
MBeanServer so that your application doesn't need to create one manually

-          Manual MBean Support. I will add support to auto register any
manually created MBeans.

-          Additional Metadata Support. In this way you can specify your
management interface metadata in XML, DB etc

-          JSR Frenzy - There are a bunch of JSR's that are JMX related that
could potentially be integrated into Spring.

 

Rob

RE: [Springframework-developer] E-Mail Templating Support

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

Okay, I see what you are saying. It does seem as though this can't be
improved that much. I think the issue here is that this approach needs =
to be
covered in the docs, or maybe a blog entry. I don't mind putting =
something
together - I will also add this to this my book...

... which leads me nicely on to asking if anyone in the team wants to do =
the
tech review on the Spring book that a colleague and I are in the process =
of
writing.

Rob

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: 21 July 2004 14:22
To: spr...@li...
Subject: Re: [Springframework-developer] E-Mail Templating Support

I'm by no means against making this even easier :-) I just don't see =
much
potential beyond what's already there, at least if just concerning mail =
body
text...

The current best practice is to use Spring's VelocityEngineFactoryBean =
to
set up a shared VelocityEngine instance, passing it to application =
objects
as bean reference into a setVelocityEngine setter. Those application =
objects
will also receive an instance of Spring's MailSender interface if they =
want
to send emails. Using VelocityEngineUtils is then very straightforward.

FreeMarker is similar: Use a FreeMarkerConfigurationFactoryBean to set =
up a
shared FreeMarker Configuration instance, for bean references. Use
FreeMarkerTemplateUtils' processTemplateIntoString to render the =
template
into a String, to be used as mail text again.

The nice thing here is that the mail support does not know anything =
about
templating; neither the other way round. To make them work in =
combination,
you just generate a String via templating and pass it into a mail =
message as
text. And the setting up of shared engine instances leverages Spring's
common IoC infrastructure, without special mechanisms.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rob Harrop
Sent: Wednesday, July 21, 2004 3:09 PM
To: spr...@li...
Subject: RE: [Springframework-developer] E-Mail Templating Support


Well that is easy, but you need to create and configure an instance of
VelocityEngine before you can use that, and that may lead to the bad
practice of creating and initializing a new instance once per message. =
It
would be a trivial job to abstract all this away, plus then we could add
support for other templating engines.

Rob

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: 21 July 2004 13:40
To: spr...@li...
Subject: Re: [Springframework-developer] E-Mail Templating Support

That's already pretty easy: You can generate the email text with the
"mergeTemplateIntoString" of Spring's VelocityTemplateUtils helper, and =
pass
the result String into SimpleMailMessage's or MimeMessageHelper's =
setText
methods. 1 line to render the template (passing in a model Map), 1 line =
to
use it as email text for a given message.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Wednesday, July 21, 2004 1:36 PM
To: spr...@li...
Subject: Re: [Springframework-developer] E-Mail Templating Support


It seems like a good number of the relatively complex j2ee apps=20
eventually end up rolling their own version of something like this (I=20
know we did at one of my last gigs, although that was before spring), so =

if you can come up with a decent abstraction this would be worthwhile.


Rob Harrop wrote:

> I have been thinking of adding templated e-mail support to the mail=20
> package in Spring. In this way you can create the body of the mail as=20
> a Velocity template, and have data passed into the mail at runtime to=20
> customize it. I need to think a little more about how this would be=20
> implemented but I think the idea is sound. What does everyone else =
think?
>
> =20
>
> Rob
>




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] E-Mail Templating Support

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

I'm by no means against making this even easier :-) I just don't see =
much potential beyond what's already there, at least if just concerning =
mail body text...

The current best practice is to use Spring's VelocityEngineFactoryBean =
to set up a shared VelocityEngine instance, passing it to application =
objects as bean reference into a setVelocityEngine setter. Those =
application objects will also receive an instance of Spring's MailSender =
interface if they want to send emails. Using VelocityEngineUtils is then =
very straightforward.

FreeMarker is similar: Use a FreeMarkerConfigurationFactoryBean to set =
up a shared FreeMarker Configuration instance, for bean references. Use =
FreeMarkerTemplateUtils' processTemplateIntoString to render the =
template into a String, to be used as mail text again.

The nice thing here is that the mail support does not know anything =
about templating; neither the other way round. To make them work in =
combination, you just generate a String via templating and pass it into =
a mail message as text. And the setting up of shared engine instances =
leverages Spring's common IoC infrastructure, without special =
mechanisms.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rob Harrop
Sent: Wednesday, July 21, 2004 3:09 PM
To: spr...@li...
Subject: RE: [Springframework-developer] E-Mail Templating Support


Well that is easy, but you need to create and configure an instance of
VelocityEngine before you can use that, and that may lead to the bad
practice of creating and initializing a new instance once per message. =
It
would be a trivial job to abstract all this away, plus then we could add
support for other templating engines.

Rob

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: 21 July 2004 13:40
To: spr...@li...
Subject: Re: [Springframework-developer] E-Mail Templating Support

That's already pretty easy: You can generate the email text with the
"mergeTemplateIntoString" of Spring's VelocityTemplateUtils helper, and =
pass
the result String into SimpleMailMessage's or MimeMessageHelper's =
setText
methods. 1 line to render the template (passing in a model Map), 1 line =
to
use it as email text for a given message.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Wednesday, July 21, 2004 1:36 PM
To: spr...@li...
Subject: Re: [Springframework-developer] E-Mail Templating Support


It seems like a good number of the relatively complex j2ee apps=20
eventually end up rolling their own version of something like this (I=20
know we did at one of my last gigs, although that was before spring), so =

if you can come up with a decent abstraction this would be worthwhile.


Rob Harrop wrote:

> I have been thinking of adding templated e-mail support to the mail=20
> package in Spring. In this way you can create the body of the mail as=20
> a Velocity template, and have data passed into the mail at runtime to=20
> customize it. I need to think a little more about how this would be=20
> implemented but I think the idea is sound. What does everyone else =
think?
>
> =20
>
> Rob
>




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] E-Mail Templating Support

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

Well that is easy, but you need to create and configure an instance of
VelocityEngine before you can use that, and that may lead to the bad
practice of creating and initializing a new instance once per message. =
It
would be a trivial job to abstract all this away, plus then we could add
support for other templating engines.

Rob

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: 21 July 2004 13:40
To: spr...@li...
Subject: Re: [Springframework-developer] E-Mail Templating Support

That's already pretty easy: You can generate the email text with the
"mergeTemplateIntoString" of Spring's VelocityTemplateUtils helper, and =
pass
the result String into SimpleMailMessage's or MimeMessageHelper's =
setText
methods. 1 line to render the template (passing in a model Map), 1 line =
to
use it as email text for a given message.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Wednesday, July 21, 2004 1:36 PM
To: spr...@li...
Subject: Re: [Springframework-developer] E-Mail Templating Support


It seems like a good number of the relatively complex j2ee apps=20
eventually end up rolling their own version of something like this (I=20
know we did at one of my last gigs, although that was before spring), so =

if you can come up with a decent abstraction this would be worthwhile.


Rob Harrop wrote:

> I have been thinking of adding templated e-mail support to the mail=20
> package in Spring. In this way you can create the body of the mail as=20
> a Velocity template, and have data passed into the mail at runtime to=20
> customize it. I need to think a little more about how this would be=20
> implemented but I think the idea is sound. What does everyone else =
think?
>
> =20
>
> Rob
>




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Property setting by base-class ra ther than class in BeanFactory

[Pavel T. <Pa...@ts...>]

D'oh :-) Sorry for the waste of bandwidth then. 

I was looking at a copy of the PDF reference which seems a bit out of date.

Cheers,
Pavel

On Wed, Jul 21, 2004 at 08:27:38AM -0400, Colin Sampaleanu wrote:
> Pavel, this already exists as child bean definitions. Take a look at
> section 3.5 in the docs below,
>   http://www.springframework.org/docs/reference/beans.html
> on 'Child bean definitions' (for some reason the direct link to that
> subsection doesn't work). Note that this code is significantly enhanced
> in CVS over v1.0.2; to get the behaviour described in the manual above
> you need CVS code.
>
> Regards,
> Colin

Re: [Springframework-developer] E-Mail Templating Support

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

That's already pretty easy: You can generate the email text with the =
"mergeTemplateIntoString" of Spring's VelocityTemplateUtils helper, and =
pass the result String into SimpleMailMessage's or MimeMessageHelper's =
setText methods. 1 line to render the template (passing in a model Map), =
1 line to use it as email text for a given message.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Wednesday, July 21, 2004 1:36 PM
To: spr...@li...
Subject: Re: [Springframework-developer] E-Mail Templating Support


It seems like a good number of the relatively complex j2ee apps=20
eventually end up rolling their own version of something like this (I=20
know we did at one of my last gigs, although that was before spring), so =

if you can come up with a decent abstraction this would be worthwhile.


Rob Harrop wrote:

> I have been thinking of adding templated e-mail support to the mail=20
> package in Spring. In this way you can create the body of the mail as=20
> a Velocity template, and have data passed into the mail at runtime to=20
> customize it. I need to think a little more about how this would be=20
> implemented but I think the idea is sound. What does everyone else =
think?
>
> =20
>
> Rob
>




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Property setting by base-class rather than class in BeanFactory

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

Pavel, this already exists as child bean definitions. Take a look at 
section 3.5 in the docs below,
  http://www.springframework.org/docs/reference/beans.html
on 'Child bean definitions' (for some reason the direct link to that 
subsection doesn't work). Note that this code is significantly enhanced 
in CVS over v1.0.2; to get the behaviour described in the manual above 
you need CVS code.

Regards,
Colin

Pavel Tcholakov wrote:

>Hi,
>
>This may have been discussed before, I did a Google search but nothing came
>up.
>
>I was reading something on spring-user yesterday when it struck me, why do
>we need to describe each and every property of each and every bean when we
>have inheritance. Sure, this may not always be the best choice, but it would
>make life easier in many cases and I would think it's relatively easy to
>implement.
>
>Possible scenario:
>
>A hierarchy of DAO objects, all extending a base DAO, which in turn extends,
>say, HibernateDaoSupport. Then instead of having in applicationContext.xml:
>
><bean id="xyzDAO" class="com.mycompany.product.dao.hibernate.XyzDAO">
>	<property name="sessionFactory">
>		<ref local="mySessionFactory">
>	</property>
>	<property name="somethingElse">
>		<value>xyz</value>
>	</property>
></bean>
>
>for each and every DAO, you could just write something like:
>
><bean superclass="com.mycompany.product.dao.hibernate.GenericDao">
>	<property name="sessionFactory">
>		<ref local="mySessionFactory">
>	</property>
></bean>
>
>And then you could still have specific properties for those beans that
>require it, like:
>
><bean id="xyzDAO" class="com.mycompany.product.dao.hibernate.XyzDAO">
>	<property name="somethingElse">
>		<value>xyz</value>
>	</property>
></bean>
>
>Yay or nay? Seems to me it's a better way of dealing with generic properties
>across the board and would make refactoring/plugging new implementations
>easier? One could even take this a step further and implement property
>setting based on regex on the bean ids or classnames much like the pointcut
>definitions in the AOP module.
>
>Best regards,
>Pavel
>  
>

[Springframework-developer] Property setting by base-class rather than class in BeanFactory

[Pavel T. <Pa...@ts...>]

Hi,

This may have been discussed before, I did a Google search but nothing came
up.

I was reading something on spring-user yesterday when it struck me, why do
we need to describe each and every property of each and every bean when we
have inheritance. Sure, this may not always be the best choice, but it would
make life easier in many cases and I would think it's relatively easy to
implement.

Possible scenario:

A hierarchy of DAO objects, all extending a base DAO, which in turn extends,
say, HibernateDaoSupport. Then instead of having in applicationContext.xml:

<bean id="xyzDAO" class="com.mycompany.product.dao.hibernate.XyzDAO">
	<property name="sessionFactory">
		<ref local="mySessionFactory">
	</property>
	<property name="somethingElse">
		<value>xyz</value>
	</property>
</bean>

for each and every DAO, you could just write something like:

<bean superclass="com.mycompany.product.dao.hibernate.GenericDao">
	<property name="sessionFactory">
		<ref local="mySessionFactory">
	</property>
</bean>

And then you could still have specific properties for those beans that
require it, like:

<bean id="xyzDAO" class="com.mycompany.product.dao.hibernate.XyzDAO">
	<property name="somethingElse">
		<value>xyz</value>
	</property>
</bean>

Yay or nay? Seems to me it's a better way of dealing with generic properties
across the board and would make refactoring/plugging new implementations
easier? One could even take this a step further and implement property
setting based on regex on the bean ids or classnames much like the pointcut
definitions in the AOP module.

Best regards,
Pavel

--
Pavel Tcholakov
Technology Systems Integration (Pty) Ltd.
Email: pa...@ts... Tel. +27 11 7921094

[Springframework-developer] Free servlet dependences

[Claudio D'A. <cla...@ob...>]

Hi,
I spossible free the instance references of the servlets of Spring in next 
release?
This is,

in DispatcherServlet.destroy method

         public void destroy() {
             super.destroy();
             this.getServletContext().removeAttribute(getServletContextAttributeName());
             this.handlerAdapters = null;
             this.handlerExceptionResolvers = null;
             this.handlerMappings = null;
             this.viewResolvers = null;
             this.multipartResolver = null;
             this.localeResolver = null;
             this.themeResolver = null;

         }

and in FrameworkServlet.destroy method
         public void destroy() {

                 getServletContext().log("Closing WebApplicationContext of 
servlet '" + getServletName());
                 if (this.webApplicationContext instanceof 
ConfigurableApplicationContext) {
                         ((ConfigurableApplicationContext) 
this.webApplicationContext).close();
                 }
                 this.webApplicationContext = null;
         }

In Weblogic this reference still blocked.

Thanks


Grazie e buon lavoro

----------
Claudio D'Angelo
Software Consultant
ObjectWay S.p.A.
Via G.A. Boltraffio 7
20159 Milano (MI)
http://www.objectway.it


-- 
La presente comunicazione potrebbe contenere informazioni riservate e/o
protette
da segreto professionale ed e' indirizzata esclusivamente ai destinatari della
medesima qui indicati. Se avete ricevuto per errore la presente comunicazione,
siete invitati a segnalarcelo, rispondendo a questo stesso indirizzo di
e-mail,
e a cancellare il presente messaggio dal Vostro sistema. E' strettamente
proibito
e potrebbe essere fonte di violazione di legge qualsiasi uso, comunicazione,
copia
o diffusione dei contenuti di questa comunicazione da parte di chi la abbia
ricevuta per errore o in violazione degli scopi della presente.
Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi
ed
e' risultato NON infetto.

Re: [Springframework-developer] E-Mail Templating Support

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

It seems like a good number of the relatively complex j2ee apps 
eventually end up rolling their own version of something like this (I 
know we did at one of my last gigs, although that was before spring), so 
if you can come up with a decent abstraction this would be worthwhile.


Rob Harrop wrote:

> I have been thinking of adding templated e-mail support to the mail 
> package in Spring. In this way you can create the body of the mail as 
> a Velocity template, and have data passed into the mail at runtime to 
> customize it. I need to think a little more about how this would be 
> implemented but I think the idea is sound. What does everyone else think?
>
>  
>
> Rob
>

[Springframework-developer] E-Mail Templating Support

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

I have been thinking of adding templated e-mail support to the mail package
in Spring. In this way you can create the body of the mail as a Velocity
template, and have data passed into the mail at runtime to customize it. I
need to think a little more about how this would be implemented but I think
the idea is sound. What does everyone else think?

 

Rob

RE: [Springframework-developer] Problem with FreeMarkerFormView...

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

> I finally found the problem thanks to your post. The thing is I find th=
e
> documentation (section 12.5.3.1) quite confusing: it binds with paths s=
uch
> as
> "command.name", "command.age", "command.address.street", etc. and I
> thought
> that instead of using the name of my command, that I had to use the
> "command"
> keyword. The doco should be clarified somehow by indicating that the bi=
nd
> path
> is from the model map and that the "command" string is not a keyword.

I'll ensure this is clarified in the relevant section of the docs.

Cheers.

--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm

RE: [Springframework-developer] Problem with FreeMarkerFormView...

[B. <jer...@xt...>]

Selon Matt Raible <li...@ra...>:

> I've got it to work, but only after modifying the build.xml in CVS to
> include *.ftl files.  Here's my template:
>
> <#import "/org/springframework/web/servlet/view/freemarker/spring.ftl"
> as spring />

I did copy it from CVS into my template path so this was not the issue I =
had
trouble with :-)

> <@spring.bind "user.*"/>
> <#if spring.status.error>
> <div class=3D"error">
>     <#list spring.status.errorMessages as error>
>         ${error}<br/>
>     </#list>
> </div>
> </#if>

I finally found the problem thanks to your post. The thing is I find the
documentation (section 12.5.3.1) quite confusing: it binds with paths suc=
h as
"command.name", "command.age", "command.address.street", etc. and I thoug=
ht
that instead of using the name of my command, that I had to use the "comm=
and"
keyword. The doco should be clarified somehow by indicating that the bind=
 path
is from the model map and that the "command" string is not a keyword.

Sorry for being too dumb :-)
Anyway, I've got this work working now!

Thanks,
J=E9r=F4me.