springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Road map

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

Let's get this on a wiki page. Confluence, please :-)

I think we should also commit on the roadmap to:

- More bean definition options, scripting and a good JDBC option. Some of
this might make 1.1; some 1.2. We should not hold 1.1 for it, but just se=
e
what's ready in time.

- Dynamic reconfiguration. I'm working on this and should have something =
in
the sandbox in the next couple of weeks. Assuming enough people are
interested in this to start kicking the tyres and helping with testing, I=
'm
optimistic we'll get it in for 1.1. I think it's an important feature.

- JSF integration: at least the easy part of it, for 1.1. Ed Burns, the s=
pec
lead, is very interested in Spring and has offered to help us with this,
which is fantastic.

I see 1.1 as an evolutionary release, without notable new concepts.

I'm also keen to work in the longer term towards anything that can furthe=
r
simplify development: for example, leveraging metadata attributes to more
things. (Anyone tried the metadata-driven web controller option, btw?) If
you have any suggestions for making developers' lives easier, please shar=
e
them, so we can make Spring even better.

Regards,
Rod


----- Original Message -----
From: <tho...@tr...>
To: <spr...@li...>
Sent: Thursday, April 01, 2004 6:09 PM
Subject: Re: [Springframework-developer] Road map


>
> From a JDBC perspective I'd like to add support for JDBC 3.0 auto
generated
> keys, maybe via an SqlInsert object.  This should be possible for 1.1.
>
> I'd also like to see support for declaring ApplicationContexts using a
scripting
> language like Jython.  This would probably be best for 1.2.
>
> James Duncan Davidson has an interesting take on Ant and XML files:
> http://x180.net/Articles/Java/AntAndXML.html
>
> Thomas
>
>
> Quoting Colin Sampaleanu <col...@ex...>:
>
> > I'll be writing a number of tools to support some people here in code
> > manipulation and debuggin, but I'm not sure exactly how much actual U=
I
> > there'll be. A fair number of them may be command-line or with simple
> > UIs, so at this point it's not a given that I'll need any sort of
> > complicated library. I'll probably be starting in about 3-4 weeks.
> >
> > As for Eclipse, I've used it for ages, but on the programming side I'=
m
> > actually a complete neophyte, although I'm itching to get into the RC=
P
stuff
> >
> > Keith Donald wrote:
> >
> > >Colin,
> > >
> > >When do you think you'll be moving to the client-side?  It'd be grea=
t
to
> > >work together.  I have a similiar requirement: I need RCP in my curr=
ent
> > >project, so I will be nicely aligned for developing the module over =
the
> > >coming months.  It would be great if you could be an early adopter a=
nd
> > >developer at the same time...
> > >
> > >If you decide to go Eclipse RCP that would be good, too.  The main
upside I
> > >think we can offer is better Swing support (Swing is more mature tha=
n
SWT,
> > >and obviously a standard) and a nice integration with the rest of
Spring.
> > >But having an Eclipse expert would be invaluable for improving our
platform
> > >capabilities.  I'd also be interested in seeing if there are ways we
can
> > >integrate with the Eclipse effort as it matures, too.
> > >
> > >Keith
> > >
> > >----- Original Message -----
> > >From: "Colin Sampaleanu" <col...@ex...>
> > >To: <spr...@li...>
> > >Sent: Wednesday, March 31, 2004 5:20 PM
> > >Subject: Re: [Springframework-developer] Road map
> > >
> > >
> > >
> > >
> > >>Actually it's looking like I may be doing some client-side work (as
> > >>opposed to the mostly back-end/web stuff I am doing now), so I may =
get
> > >>involved. Haven't decided if I want to do the stuff in Swing or
Eclipse
> > >>RCP though...
> > >>
> > >>
> > >>Keith Donald wrote:
> > >>
> > >>
> > >>
> > >>>Just like to add to the pot here regarding spring-rcp (especially
since
> > >>>
> > >>>
> > >work
> > >
> > >
> > >>>is picking back up now):
> > >>>
> > >>>- I'd like to target the first 1.0 RCP release candidate along sid=
e
> > >>>
> > >>>
> > >Spring
> > >
> > >
> > >>>1.1 final this summer.
> > >>>
> > >>>We plan to include in the distribution a sample application
demonstrating
> > >>>the features of the platform (likely a port of the PetClinic or
Thomas's
> > >>>Beer app, adding RCP value like 'quick' sorting/filtering and
as-you-type
> > >>>field validation.)  I am hopeful by the first release we'll have
several
> > >>>articles lined up, too (I know several people interested in rich
client
> > >>>
> > >>>
> > >dev
> > >
> > >
> > >>>have expressed interest in helping out there!)
> > >>>
> > >>>Thanks,
> > >>>Keith
> > >>>
> > >>>
> > >>>-----Original Message-----
> > >>>From: spr...@li...
> > >>>[mailto:spr...@li...] On
Behalf
> > >>>
> > >>>
> > >Of
> > >
> > >
> > >>>j=FCrgen h=F6ller [werk3AT]
> > >>>Sent: Wednesday, March 31, 2004 9:44 AM
> > >>>To: spr...@li...
> > >>>Subject: Re: [Springframework-developer] Road map
> > >>>
> > >>>
> > >>>Good point regarding scheduling 1.1.1. I've intended to fill in a
> > >>>placeholder to make the gap to 1.2 RC1 seem less large ;-) I
completely
> > >>>agree that we shouldn't schedule such point releases in an officia=
l
> > >>>
> > >>>
> > >release
> > >
> > >
> > >>>plan.
> > >>>
> > >>>If we manage to get JSF and/or Portlet support done in time for 1.=
1,
then
> > >>>I'm all for including it earlier. I'd like to release 1.1 final by
the
> > >>>
> > >>>
> > >end
> > >
> > >
> > >>>of August, though; I don't want to delay it for further features.
> > >>>
> > >>>Juergen
> > >>>
> > >>>
> > >>>-----Original Message-----
> > >>>From: spr...@li...
> > >>>[mailto:spr...@li...]On
Behalf
> > >>>
> > >>>
> > >Of
> > >
> > >
> > >>>Rod Johnson
> > >>>Sent: Wednesday, March 31, 2004 2:41 PM
> > >>>To: spr...@li...
> > >>>Subject: Re: [Springframework-developer] Road map
> > >>>
> > >>>
> > >>>Some comments:
> > >>>
> > >>>Spring 1.0.x: doc polishing, bugfixing, minor enhancements
> > >>>- 1.0.1: early April
> > >>>- 1.0.2: late May
> > >>>
> > >>>Spring 1.1.x: JMS support, JMX support, declarative validation
> > >>>[RJ: pointcut expression language (AOP), JSR-175 preview? ]
> > >>>- 1.1 RC1: early July
> > >>>- 1.1 final: late August
> > >>>- 1.1.1: late September
> > >>>[RJ: why are we _scheduling_ a 1.1.1?]
> > >>>
> > >>>Spring 1.2.x: OGNL support, JCA support, enhanced RMI support
> > >>>- 1.2 RC1: early November
> > >>>- 1.2 final: late December
> > >>>
> > >>>Further issues are JSF and Portlet support. There is actually quit=
e a
bit
> > >>>
> > >>>
> > >of
> > >
> > >
> > >>>interest in these from various users/integrators; they are also
important
> > >>>for us from a marketing perspective. I'm not keen on providing
official
> > >>>support before 1.2, though.
> > >>>
> > >>>[RJ: depends on what's involved. I'd be keen to have JSF support
sooner
> > >>>rather than later if it's straightforward. I'm going to be looking=
 at
> > >>>
> > >>>
> > >that
> > >
> > >
> > >>>soon. Portlets I think are more of a niche interest. ]
> > >>>
> > >>>Regards,
> > >>>Juergen
> > >>>
> > >>>
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3D=
click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-develope=
r
> >
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc=
lick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Prototype JMS framework

[Mark P. <Mar...@Co...>]

Hi Patrick,

Thanks, the code does look useful, in particular the JmsBeanConfig that
sets/dispatches connection consumers.   I've found a few JMS impls that
don't support section 8 of the jms spec (connection consumers), since it
is optional, and I've went in a different direction but anyway, I'll be
going over JMS this week to sort it all out.  Andre Biryukov is also
contributing.

A quick listing of the direction I'd like to see spring JMS go is to
abstract out the diff between queue/topic usage (seems 1.1 usage is not
wide spread), provide an easy to use msg gateway for sending messages, and
help out greatly on the receive part by doing such things as configuring a
listener to use generic selector implementation in the sandbox to abstract
out the ugly switch like statements you have often in message listeners,
provide a message listener with a template method for duplicate messges,
and so supply a message->bean converter.  Not a complete list, but gives
you a general idea of things.  We will be looking at commons-messenger to
see what is useful there as well.

Cheers,
Mark


> Patrick,
>
> the JMS support is currently in the works and is scheduled for 1.1
> release. Take a look at the "sandbox" module in the CVS repo.
>
> Regards,
> Dmitriy.
>
> ----- Original Message -----
> From: Patrick Higgins <phi...@tr...>
> Date: Friday, April 2, 2004 9:31 pm
> Subject: [Springframework-developer] Prototype JMS framework
>
>> I don't know if anyone else is already working on this, but I need to
>> write MessageDrivenBean-like code for my job, so I've started on
>> it this
>> week using Spring.
>>
>> The code I've written so far can be obtained at
>> http://www.oildex.com/jwget/oildex-jms.tar.gz
>>
>> I haven't ever looked at Spring's code, so I apologize in advance for
>> following a different coding style, unless by some miracle I
>> happen to
>> code the same way!
>>
>> I'd like to help get this work into Spring 1.1, so take a look at it,
>> make suggestions, patches, etc.
>>
>> Also, I haven't put any copyright notices into the code yet, but it's
>> licensed under the Apache License version 2.0 to be compatible with
>> Spring.
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IBM Linux Tutorials
>> Free Linux tutorial presented by Daniel Robbins, President and CEO of
>> GenToo technologies. Learn everything from fundamentals to system
>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] J2EE Connector Architecture support

[Diego D. <di...@gm...>]

Folks,
   we are currently working on J2EE Connector Architecture (formerly called
JCA, nowadays JCA stands for Java Criptography API) Spring support proposal.

   Some issues we are covering:
      *) CCI abstraction based on JdbcTemplate (a similar fashion way)
      *) object abstraction based on JDO API
      *) transaction support
      *) exception handling
      *) object handling based on metadata and reflection

   We are going to introduce a technical proposal next week-end. We are
ready to accept any suggestion you could send to us, specially if someone was
already working on the same topic.

-- 
______________________________________
   Hans Nemarich (nem...@cm...)
   Diego Dagum (di...@gm...)

+++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz

Re: [Springframework-developer] Preparing for 1.0.1

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

+1

jürgen höller [werk3AT] wrote:

>A minor naming issue that I've noticed: We have an AbstractPrototypeTargetSource, which serves as base class for PrototypeTargetSource, ThreadLocalTargetSource and AbstractPoolingTargetSource. We don't have the AbstractXxx/Xxx naming pattern anywhere else in the framework. (I've actually removed a similar naming pattern in the AbstractAutoProxyCreator area before 1.0 final.)
> 
>Furthermore, "AbstractPrototypeTargetSource" is actually a bit misleading, as we're using a broader meaning of the word prototype here than found in bean definitions. "PrototypeTargetSource" matches the bean definition term exactly, but the base class is more generic: So what about renaming it to "AbstractDynamicTargetSource" or the like, indicating that it serves as base class for all non-singleton TargetSources?
> 
>Like the AopUtils move, this should be fine in terms of compatibility level, as the base class is not part of the public API but rather an internal implementation detail. PrototypeTargetSource and co will still be fully backward compatible after that change, and I doubt that anyone has implemented custom TargetSources yet (and even if, it's trivial to adapt).
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Rod Johnson
>Gesendet: Fr 02.04.2004 16:53
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Preparing for 1.0.1
>
>
>
>I suggest that we sit on this code for at least a week until we release it,
>so we can catch anything else. How about we target Monday week for release?
>
>A 1.0.1 release should be driven by stability, not date, so we should see if
>any more issues come out of the woodwork.
>
>----- Original Message -----
>From: "jürgen höller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Friday, April 02, 2004 10:57 AM
>Subject: [Springframework-developer] Preparing for 1.0.1
>
>
>Hi everybody,
>
>From my point of view, the code is ready for release 1.0.1. There were a
>couple of bug fixes and minor enhancements since 1.0 final. The most
>important fix is proper Hibernate/JTA resource management when flush fails.
>Enhancements include the introduction of the MessageCodesResolver interface
>in the validation package, and a more efficient internal implementation of
>AbstractMessageSource. See the changelog for details.
>
>Please give the current CVS snapshot a try. There shouldn't be any issues,
>as changes are minor and just affect specific functionality. I'd like to
>target mid next week for the release, i.e. two weeks after 1.0 final. In the
>meantime, the only thing I plan to address is the lack of remoting coverage
>in the reference docs. If anyone feels the need to improve other parts of
>the docs, please do so till mid next week!
>
>Juergen
>  
>

Re: [Springframework-developer] Preparing for 1.0.1

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

A minor naming issue that I've noticed: We have an =
AbstractPrototypeTargetSource, which serves as base class for =
PrototypeTargetSource, ThreadLocalTargetSource and =
AbstractPoolingTargetSource. We don't have the AbstractXxx/Xxx naming =
pattern anywhere else in the framework. (I've actually removed a similar =
naming pattern in the AbstractAutoProxyCreator area before 1.0 final.)
=20
Furthermore, "AbstractPrototypeTargetSource" is actually a bit =
misleading, as we're using a broader meaning of the word prototype here =
than found in bean definitions. "PrototypeTargetSource" matches the bean =
definition term exactly, but the base class is more generic: So what =
about renaming it to "AbstractDynamicTargetSource" or the like, =
indicating that it serves as base class for all non-singleton =
TargetSources?
=20
Like the AopUtils move, this should be fine in terms of compatibility =
level, as the base class is not part of the public API but rather an =
internal implementation detail. PrototypeTargetSource and co will still =
be fully backward compatible after that change, and I doubt that anyone =
has implemented custom TargetSources yet (and even if, it's trivial to =
adapt).
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: Fr 02.04.2004 16:53
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



I suggest that we sit on this code for at least a week until we release =
it,
so we can catch anything else. How about we target Monday week for =
release?

A 1.0.1 release should be driven by stability, not date, so we should =
see if
any more issues come out of the woodwork.

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Friday, April 02, 2004 10:57 AM
Subject: [Springframework-developer] Preparing for 1.0.1


Hi everybody,

From my point of view, the code is ready for release 1.0.1. There were a
couple of bug fixes and minor enhancements since 1.0 final. The most
important fix is proper Hibernate/JTA resource management when flush =
fails.
Enhancements include the introduction of the MessageCodesResolver =
interface
in the validation package, and a more efficient internal implementation =
of
AbstractMessageSource. See the changelog for details.

Please give the current CVS snapshot a try. There shouldn't be any =
issues,
as changes are minor and just affect specific functionality. I'd like to
target mid next week for the release, i.e. two weeks after 1.0 final. In =
the
meantime, the only thing I plan to address is the lack of remoting =
coverage
in the reference docs. If anyone feels the need to improve other parts =
of
the docs, please do so till mid next week!

Juergen


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Sandbox building targets available

[Cameron B. <ca...@da...>]

You must have read my mind.. I was thinking that something like that would
be handy ;)

 

Thanks,

 

Cameron

 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Alef Arendsen
Sent: Sunday, 4 April 2004 1:01 AM
To: spr...@li...
Subject: [Springframework-developer] Sandbox building targets available

 

All,

 

I've added target to build.xml for building the sandbox.

 

-       build-sandbox - builds the sandbox (compilation)

-       buildtests-sandbox - build the tests for the sanbox

-       tests-sandbox - tests the sandbox

-       sanboxjar (alongside modulejars, fulljar) - creates a spring.jar
including sandbox classes

 

regards,

Alef

 

[Springframework-developer] Sandbox building targets available

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

All,

 

I've added target to build.xml for building the sandbox.

 

-        build-sandbox - builds the sandbox (compilation)

-        buildtests-sandbox - build the tests for the sanbox

-        tests-sandbox - tests the sandbox

-        sanboxjar (alongside modulejars, fulljar) - creates a spring.jar
including sandbox classes

 

regards,

Alef

 

RE: [Springframework-developer] Preparing for 1.0.1

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

I tend to be in favor of waiting a little while. Tiny issues keep coming =
up
and I guess it's worth waiting for some more. As Rod says, stability is =
key,
no need to rush here...

In the meantime I think we should inform users of major issues (like the
Hibernate one) in a more prominent way however, along with some =
potential
workarounds...

Alef


> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of Colin Sampaleanu
> Sent: Friday, April 02, 2004 11:43 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Preparing for 1.0.1
>=20
> +0
>=20
> I agree for the most part with trying to catch other issues, however =
the
> Hibernate session bug is _very_ nasty for people that actually get hit
> by it. Now those people can pull out and run a CVS if they think to =
come
> here and ask, but still...
>=20
> Rod Johnson wrote:
>=20
> >I suggest that we sit on this code for at least a week until we =
release
> it,
> >so we can catch anything else. How about we target Monday week for
> release?
> >
> >A 1.0.1 release should be driven by stability, not date, so we should =
see
> if
> >any more issues come out of the woodwork.
> >
> >----- Original Message -----
> >From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> >To: <spr...@li...>
> >Sent: Friday, April 02, 2004 10:57 AM
> >Subject: [Springframework-developer] Preparing for 1.0.1
> >
> >
> >Hi everybody,
> >
> >From my point of view, the code is ready for release 1.0.1. There =
were a
> >couple of bug fixes and minor enhancements since 1.0 final. The most
> >important fix is proper Hibernate/JTA resource management when flush
> fails.
> >Enhancements include the introduction of the MessageCodesResolver
> interface
> >in the validation package, and a more efficient internal =
implementation
> of
> >AbstractMessageSource. See the changelog for details.
> >
> >Please give the current CVS snapshot a try. There shouldn't be any
> issues,
> >as changes are minor and just affect specific functionality. I'd like =
to
> >target mid next week for the release, i.e. two weeks after 1.0 final. =
In
> the
> >meantime, the only thing I plan to address is the lack of remoting
> coverage
> >in the reference docs. If anyone feels the need to improve other =
parts of
> >the docs, please do so till mid next week!
> >
> >Juergen
> >
> >
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Groovy / Jython (was: Road map)

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

Err,

Been able to get a beanfactory up-and-running, however, not in a way as
elegant as I wanted it to be, but that's something that's probably going =
to
take some more time and thinking. It's something like this, and I don't =
like
it ;-)

test =3D new BeanDef (age:8,name:'susan')
test.singleton =3D true
test.dependencyCheck =3D PRIMITIVES

est =3D new BeanDef (age:10)
est.name=3D'jim'
est.spouse=3Dtest
est.singleton =3D false

I'm not entirely sure how to go about the dependencies and properties of =
a
bean versus the behavioral stuff (singleton, dependency checking, =
etcetera).
For sure we need some extra stuff here (i.e. some kind of wrapper around =
the
BeanDefinition class--the BeanDef class in the script above), I don't =
think
dealing with MutablePropertyValue objects in a Groovy script directly is =
the
way to go. But maybe you noticed the problem in the script above =
already:
you can't have dependencies named 'singleton' or 'dependencyCheck' here. =
So
maybe including some kind of metadata object might be an option.

By the way, from my point of view, there's a difference between reading =
in
and modifying a applicationcontext and its beandefinition and actually
approaching/using it at runtime. Currently I'm only thinking about the
former... Using it from Groovy scripts however could be quite something =
as
well!

Regards,
Alef




> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of Darren Davison
> Sent: Saturday, April 03, 2004 1:01 PM
> To: spr...@li...
> Subject: [Springframework-developer] Groovy / Jython (was: Road map)
>=20
> On Saturday 03 April 2004 09:47, Alef Arendsen wrote:
>=20
> > It would be nice to have something in the sandbox indeed. I'm =
currently
> > experimenting with a GroovyBeanDefinitionReader and it seems it's =
not
> > going to be all that tough to get it running!
>=20
> snap!
>=20
> I started looking at something similar in both Groovy and Jython =
(partly
> to
> see which of those two was 'best').  Thought it may be very useful for
> writing tests or certain deployment scripts.
>=20
> How far have you got with it?
>=20
> --
>=20
> Darren Davison
> Public Key: http://www.davison.uk.net/key.jsp
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Groovy / Jython (was: Road map)

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

On Saturday 03 April 2004 09:47, Alef Arendsen wrote:

> It would be nice to have something in the sandbox indeed. I'm currently
> experimenting with a GroovyBeanDefinitionReader and it seems it's not
> going to be all that tough to get it running!

snap!

I started looking at something similar in both Groovy and Jython (partly to 
see which of those two was 'best').  Thought it may be very useful for 
writing tests or certain deployment scripts.

How far have you got with it?

-- 

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

RE: [Springframework-developer] Road map

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

Hot reloadable contexts is pretty cool!

It would be nice to have something in the sandbox indeed. I'm currently
experimenting with a GroovyBeanDefinitionReader and it seems it's not =
going
to be all that tough to get it running!

Furthermore I like to see if it's possible to modify existing
beanfactories/appcontexts with Groovy.

Alef


> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of Rod Johnson
> Sent: Saturday, April 03, 2004 12:09 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Road map
>=20
> Absolutely agree. XML shouldn't be the only major config choice,
> especially
> now we've nicely decoupled bean definition registries from readers.
>=20
> It looks like Groovy really has a lot of momentum now.
>=20
> Another configuration option I'll be looking at shortly is improved
> database
> storage. I'm going to need this for a client.
>=20
> I'm also looking at hot reload of contexts. I should have something in =
the
> sandbox in the next week or so. It looks quite exciting, and enables =
any
> bean definition to be modified: even to have different dependencies.
>=20
> Regards,
> Rod
>=20
> ----- Original Message -----
> From: "Keith Donald" <kd...@cs...>
> To: <spr...@li...>
> Sent: Thursday, April 01, 2004 7:59 PM
> Subject: RE: [Springframework-developer] Road map
>=20
>=20
> I think experimenting with integration with scripting languages like
> Groovy/Beanshell/Jython for configuration sounds like a great idea.  I
> like
> how lists, maps, and properties are "first class citizens."
>=20
> Groovy was just accepted as a JSR which I find interesting! Keith
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of
> tho...@tr...
> Sent: Thursday, April 01, 2004 12:09 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Road map
>=20
>=20
>=20
> >From a JDBC perspective I'd like to add support for JDBC 3.0 auto
> >generated
> keys, maybe via an SqlInsert object.  This should be possible for 1.1.
>=20
> I'd also like to see support for declaring ApplicationContexts using a
> scripting language like Jython.  This would probably be best for 1.2.
>=20
> James Duncan Davidson has an interesting take on Ant and XML files:
> http://x180.net/Articles/Java/AntAndXML.html
>=20
> Thomas
>=20
>=20
> Quoting Colin Sampaleanu <col...@ex...>:
>=20
> > I'll be writing a number of tools to support some people here in =
code
> > manipulation and debuggin, but I'm not sure exactly how much actual =
UI
> > there'll be. A fair number of them may be command-line or with =
simple
> > UIs, so at this point it's not a given that I'll need any sort of
> > complicated library. I'll probably be starting in about 3-4 weeks.
> >
> > As for Eclipse, I've used it for ages, but on the programming side =
I'm
> > actually a complete neophyte, although I'm itching to get into the =
RCP
> stuff
> >
> > Keith Donald wrote:
> >
> > >Colin,
> > >
> > >When do you think you'll be moving to the client-side?  It'd be =
great
> > >to work together.  I have a similiar requirement: I need RCP in my
> > >current project, so I will be nicely aligned for developing the
> > >module over the coming months.  It would be great if you could be =
an
> > >early adopter and developer at the same time...
> > >
> > >If you decide to go Eclipse RCP that would be good, too.  The main
> > >upside I think we can offer is better Swing support (Swing is more
> > >mature than SWT, and obviously a standard) and a nice integration
> > >with the rest of Spring. But having an Eclipse expert would be
> > >invaluable for improving our platform capabilities.  I'd also be
> > >interested in seeing if there are ways we can integrate with the
> > >Eclipse effort as it matures, too.
> > >
> > >Keith
> > >
> > >----- Original Message -----
> > >From: "Colin Sampaleanu" <col...@ex...>
> > >To: <spr...@li...>
> > >Sent: Wednesday, March 31, 2004 5:20 PM
> > >Subject: Re: [Springframework-developer] Road map
> > >
> > >
> > >
> > >
> > >>Actually it's looking like I may be doing some client-side work =
(as
> > >>opposed to the mostly back-end/web stuff I am doing now), so I may
> > >>get involved. Haven't decided if I want to do the stuff in Swing =
or
> > >>Eclipse RCP though...
> > >>
> > >>
> > >>Keith Donald wrote:
> > >>
> > >>
> > >>
> > >>>Just like to add to the pot here regarding spring-rcp (especially
> > >>>since
> > >>>
> > >>>
> > >work
> > >
> > >
> > >>>is picking back up now):
> > >>>
> > >>>- I'd like to target the first 1.0 RCP release candidate along =
side
> > >>>
> > >>>
> > >Spring
> > >
> > >
> > >>>1.1 final this summer.
> > >>>
> > >>>We plan to include in the distribution a sample application
> > >>>demonstrating the features of the platform (likely a port of the
> > >>>PetClinic or Thomas's Beer app, adding RCP value like 'quick'
> > >>>sorting/filtering and as-you-type field validation.)  I am =
hopeful
> > >>>by the first release we'll have several articles lined up, too (I
> > >>>know several people interested in rich client
> > >>>
> > >>>
> > >dev
> > >
> > >
> > >>>have expressed interest in helping out there!)
> > >>>
> > >>>Thanks,
> > >>>Keith
> > >>>
> > >>>
> > >>>-----Original Message-----
> > >>>From: spr...@li...
> > >>>[mailto:spr...@li...] On
> > >>>Behalf
> > >>>
> > >>>
> > >Of
> > >
> > >
> > >>>j=FCrgen h=F6ller [werk3AT]
> > >>>Sent: Wednesday, March 31, 2004 9:44 AM
> > >>>To: spr...@li...
> > >>>Subject: Re: [Springframework-developer] Road map
> > >>>
> > >>>
> > >>>Good point regarding scheduling 1.1.1. I've intended to fill in a
> > >>>placeholder to make the gap to 1.2 RC1 seem less large ;-) I
> > >>>completely agree that we shouldn't schedule such point releases =
in
> > >>>an official
> > >>>
> > >>>
> > >release
> > >
> > >
> > >>>plan.
> > >>>
> > >>>If we manage to get JSF and/or Portlet support done in time for
> > >>>1.1, then I'm all for including it earlier. I'd like to release =
1.1
> > >>>final by the
> > >>>
> > >>>
> > >end
> > >
> > >
> > >>>of August, though; I don't want to delay it for further features.
> > >>>
> > >>>Juergen
> > >>>
> > >>>
> > >>>-----Original Message-----
> > >>>From: spr...@li...
> > >>>[mailto:spr...@li...]On
> > >>>Behalf
> > >>>
> > >>>
> > >Of
> > >
> > >
> > >>>Rod Johnson
> > >>>Sent: Wednesday, March 31, 2004 2:41 PM
> > >>>To: spr...@li...
> > >>>Subject: Re: [Springframework-developer] Road map
> > >>>
> > >>>
> > >>>Some comments:
> > >>>
> > >>>Spring 1.0.x: doc polishing, bugfixing, minor enhancements
> > >>>- 1.0.1: early April
> > >>>- 1.0.2: late May
> > >>>
> > >>>Spring 1.1.x: JMS support, JMX support, declarative validation
> > >>>[RJ: pointcut expression language (AOP), JSR-175 preview? ]
> > >>>- 1.1 RC1: early July
> > >>>- 1.1 final: late August
> > >>>- 1.1.1: late September
> > >>>[RJ: why are we _scheduling_ a 1.1.1?]
> > >>>
> > >>>Spring 1.2.x: OGNL support, JCA support, enhanced RMI support
> > >>>- 1.2 RC1: early November
> > >>>- 1.2 final: late December
> > >>>
> > >>>Further issues are JSF and Portlet support. There is actually =
quite
> > >>>a bit
> > >>>
> > >>>
> > >of
> > >
> > >
> > >>>interest in these from various users/integrators; they are also
> > >>>important for us from a marketing perspective. I'm not keen on
> > >>>providing official support before 1.2, though.
> > >>>
> > >>>[RJ: depends on what's involved. I'd be keen to have JSF support
> > >>>sooner rather than later if it's straightforward. I'm going to be
> > >>>looking at
> > >>>
> > >>>
> > >that
> > >
> > >
> > >>>soon. Portlets I think are more of a niche interest. ]
> > >>>
> > >>>Regards,
> > >>>Juergen
> > >>>
> > >>>
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO =
of
> > GenToo technologies. Learn everything from fundamentals to system
> > =
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo
> technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Prototype JMS framework

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

Patrick,

the JMS support is currently in the works and is scheduled for 1.1 release. Take a look at the "sandbox" module in the CVS repo.

Regards,
Dmitriy.

----- Original Message -----
From: Patrick Higgins <phi...@tr...>
Date: Friday, April 2, 2004 9:31 pm
Subject: [Springframework-developer] Prototype JMS framework

> I don't know if anyone else is already working on this, but I need to
> write MessageDrivenBean-like code for my job, so I've started on 
> it this
> week using Spring.
> 
> The code I've written so far can be obtained at
> http://www.oildex.com/jwget/oildex-jms.tar.gz
> 
> I haven't ever looked at Spring's code, so I apologize in advance for
> following a different coding style, unless by some miracle I 
> happen to
> code the same way!
> 
> I'd like to help get this work into Spring 1.1, so take a look at it,
> make suggestions, patches, etc.
> 
> Also, I haven't put any copyright notices into the code yet, but it's
> licensed under the Apache License version 2.0 to be compatible with
> Spring.
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

[Springframework-developer] Prototype JMS framework

[Patrick H. <phi...@tr...>]

I don't know if anyone else is already working on this, but I need to
write MessageDrivenBean-like code for my job, so I've started on it this
week using Spring.

The code I've written so far can be obtained at
http://www.oildex.com/jwget/oildex-jms.tar.gz

I haven't ever looked at Spring's code, so I apologize in advance for
following a different coding style, unless by some miracle I happen to
code the same way!

I'd like to help get this work into Spring 1.1, so take a look at it,
make suggestions, patches, etc.

Also, I haven't put any copyright notices into the code yet, but it's
licensed under the Apache License version 2.0 to be compatible with
Spring.

Re: [Springframework-developer] Road map

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

How about JMX enabled BeanFactory/ApplicationConetext exposed via HTTP adaptor?

Regards,
Dmitriy.

----- Original Message -----
From: Andy Depue <an...@ma...>
Date: Friday, April 2, 2004 6:16 pm
Subject: Re: [Springframework-developer] Road map

> On Friday 02 April 2004 02:09 pm, Rod Johnson wrote:
> 
> > ...
> > Another configuration option I'll be looking at shortly is improved
> > database storage. I'm going to need this for a client.
> > 
> > I'm also looking at hot reload of contexts. I should have 
> something in the
> > sandbox in the next week or so. It looks quite exciting, and 
> enables any
> > bean definition to be modified: even to have different dependencies.
> 
> I'll put my vote in for these two options.  Eventually, we desire 
> to have a 
> web based administration console for our application, and with 
> Spring 
> configuration stored in the DB, along with hot reload, we could 
> enable an 
> Administrator to tweak applicable configuration options dynamically.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] Road map

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

On Friday 02 April 2004 02:09 pm, Rod Johnson wrote:

> ...
> Another configuration option I'll be looking at shortly is improved
> database storage. I'm going to need this for a client.
> 
> I'm also looking at hot reload of contexts. I should have something in the
> sandbox in the next week or so. It looks quite exciting, and enables any
> bean definition to be modified: even to have different dependencies.

I'll put my vote in for these two options.  Eventually, we desire to have a 
web based administration console for our application, and with Spring 
configuration stored in the DB, along with hot reload, we could enable an 
Administrator to tweak applicable configuration options dynamically.

Re: [Springframework-developer] Road map

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

Absolutely agree. XML shouldn't be the only major config choice, especial=
ly
now we've nicely decoupled bean definition registries from readers.

It looks like Groovy really has a lot of momentum now.

Another configuration option I'll be looking at shortly is improved datab=
ase
storage. I'm going to need this for a client.

I'm also looking at hot reload of contexts. I should have something in th=
e
sandbox in the next week or so. It looks quite exciting, and enables any
bean definition to be modified: even to have different dependencies.

Regards,
Rod

----- Original Message -----
From: "Keith Donald" <kd...@cs...>
To: <spr...@li...>
Sent: Thursday, April 01, 2004 7:59 PM
Subject: RE: [Springframework-developer] Road map


I think experimenting with integration with scripting languages like
Groovy/Beanshell/Jython for configuration sounds like a great idea.  I li=
ke
how lists, maps, and properties are "first class citizens."

Groovy was just accepted as a JSR which I find interesting! Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
tho...@tr...
Sent: Thursday, April 01, 2004 12:09 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Road map



>From a JDBC perspective I'd like to add support for JDBC 3.0 auto
>generated
keys, maybe via an SqlInsert object.  This should be possible for 1.1.

I'd also like to see support for declaring ApplicationContexts using a
scripting language like Jython.  This would probably be best for 1.2.

James Duncan Davidson has an interesting take on Ant and XML files:
http://x180.net/Articles/Java/AntAndXML.html

Thomas


Quoting Colin Sampaleanu <col...@ex...>:

> I'll be writing a number of tools to support some people here in code
> manipulation and debuggin, but I'm not sure exactly how much actual UI
> there'll be. A fair number of them may be command-line or with simple
> UIs, so at this point it's not a given that I'll need any sort of
> complicated library. I'll probably be starting in about 3-4 weeks.
>
> As for Eclipse, I've used it for ages, but on the programming side I'm
> actually a complete neophyte, although I'm itching to get into the RCP
stuff
>
> Keith Donald wrote:
>
> >Colin,
> >
> >When do you think you'll be moving to the client-side?  It'd be great
> >to work together.  I have a similiar requirement: I need RCP in my
> >current project, so I will be nicely aligned for developing the
> >module over the coming months.  It would be great if you could be an
> >early adopter and developer at the same time...
> >
> >If you decide to go Eclipse RCP that would be good, too.  The main
> >upside I think we can offer is better Swing support (Swing is more
> >mature than SWT, and obviously a standard) and a nice integration
> >with the rest of Spring. But having an Eclipse expert would be
> >invaluable for improving our platform capabilities.  I'd also be
> >interested in seeing if there are ways we can integrate with the
> >Eclipse effort as it matures, too.
> >
> >Keith
> >
> >----- Original Message -----
> >From: "Colin Sampaleanu" <col...@ex...>
> >To: <spr...@li...>
> >Sent: Wednesday, March 31, 2004 5:20 PM
> >Subject: Re: [Springframework-developer] Road map
> >
> >
> >
> >
> >>Actually it's looking like I may be doing some client-side work (as
> >>opposed to the mostly back-end/web stuff I am doing now), so I may
> >>get involved. Haven't decided if I want to do the stuff in Swing or
> >>Eclipse RCP though...
> >>
> >>
> >>Keith Donald wrote:
> >>
> >>
> >>
> >>>Just like to add to the pot here regarding spring-rcp (especially
> >>>since
> >>>
> >>>
> >work
> >
> >
> >>>is picking back up now):
> >>>
> >>>- I'd like to target the first 1.0 RCP release candidate along side
> >>>
> >>>
> >Spring
> >
> >
> >>>1.1 final this summer.
> >>>
> >>>We plan to include in the distribution a sample application
> >>>demonstrating the features of the platform (likely a port of the
> >>>PetClinic or Thomas's Beer app, adding RCP value like 'quick'
> >>>sorting/filtering and as-you-type field validation.)  I am hopeful
> >>>by the first release we'll have several articles lined up, too (I
> >>>know several people interested in rich client
> >>>
> >>>
> >dev
> >
> >
> >>>have expressed interest in helping out there!)
> >>>
> >>>Thanks,
> >>>Keith
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: spr...@li...
> >>>[mailto:spr...@li...] On
> >>>Behalf
> >>>
> >>>
> >Of
> >
> >
> >>>j=FCrgen h=F6ller [werk3AT]
> >>>Sent: Wednesday, March 31, 2004 9:44 AM
> >>>To: spr...@li...
> >>>Subject: Re: [Springframework-developer] Road map
> >>>
> >>>
> >>>Good point regarding scheduling 1.1.1. I've intended to fill in a
> >>>placeholder to make the gap to 1.2 RC1 seem less large ;-) I
> >>>completely agree that we shouldn't schedule such point releases in
> >>>an official
> >>>
> >>>
> >release
> >
> >
> >>>plan.
> >>>
> >>>If we manage to get JSF and/or Portlet support done in time for
> >>>1.1, then I'm all for including it earlier. I'd like to release 1.1
> >>>final by the
> >>>
> >>>
> >end
> >
> >
> >>>of August, though; I don't want to delay it for further features.
> >>>
> >>>Juergen
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: spr...@li...
> >>>[mailto:spr...@li...]On
> >>>Behalf
> >>>
> >>>
> >Of
> >
> >
> >>>Rod Johnson
> >>>Sent: Wednesday, March 31, 2004 2:41 PM
> >>>To: spr...@li...
> >>>Subject: Re: [Springframework-developer] Road map
> >>>
> >>>
> >>>Some comments:
> >>>
> >>>Spring 1.0.x: doc polishing, bugfixing, minor enhancements
> >>>- 1.0.1: early April
> >>>- 1.0.2: late May
> >>>
> >>>Spring 1.1.x: JMS support, JMX support, declarative validation
> >>>[RJ: pointcut expression language (AOP), JSR-175 preview? ]
> >>>- 1.1 RC1: early July
> >>>- 1.1 final: late August
> >>>- 1.1.1: late September
> >>>[RJ: why are we _scheduling_ a 1.1.1?]
> >>>
> >>>Spring 1.2.x: OGNL support, JCA support, enhanced RMI support
> >>>- 1.2 RC1: early November
> >>>- 1.2 final: late December
> >>>
> >>>Further issues are JSF and Portlet support. There is actually quite
> >>>a bit
> >>>
> >>>
> >of
> >
> >
> >>>interest in these from various users/integrators; they are also
> >>>important for us from a marketing perspective. I'm not keen on
> >>>providing official support before 1.2, though.
> >>>
> >>>[RJ: depends on what's involved. I'd be keen to have JSF support
> >>>sooner rather than later if it's straightforward. I'm going to be
> >>>looking at
> >>>
> >>>
> >that
> >
> >
> >>>soon. Portlets I think are more of a niche interest. ]
> >>>
> >>>Regards,
> >>>Juergen
> >>>
> >>>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc=
lick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>





-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of Gen=
Too
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Preparing for 1.0.1

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

+0

I agree for the most part with trying to catch other issues, however the=20
Hibernate session bug is _very_ nasty for people that actually get hit=20
by it. Now those people can pull out and run a CVS if they think to come=20
here and ask, but still...

Rod Johnson wrote:

>I suggest that we sit on this code for at least a week until we release =
it,
>so we can catch anything else. How about we target Monday week for relea=
se?
>
>A 1.0.1 release should be driven by stability, not date, so we should se=
e if
>any more issues come out of the woodwork.
>
>----- Original Message -----
>From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Friday, April 02, 2004 10:57 AM
>Subject: [Springframework-developer] Preparing for 1.0.1
>
>
>Hi everybody,
>
>From my point of view, the code is ready for release 1.0.1. There were a
>couple of bug fixes and minor enhancements since 1.0 final. The most
>important fix is proper Hibernate/JTA resource management when flush fai=
ls.
>Enhancements include the introduction of the MessageCodesResolver interf=
ace
>in the validation package, and a more efficient internal implementation =
of
>AbstractMessageSource. See the changelog for details.
>
>Please give the current CVS snapshot a try. There shouldn't be any issue=
s,
>as changes are minor and just affect specific functionality. I'd like to
>target mid next week for the release, i.e. two weeks after 1.0 final. In=
 the
>meantime, the only thing I plan to address is the lack of remoting cover=
age
>in the reference docs. If anyone feels the need to improve other parts o=
f
>the docs, please do so till mid next week!
>
>Juergen
> =20
>

Re: [Springframework-developer] Preparing for 1.0.1

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

I suggest that we sit on this code for at least a week until we release i=
t,
so we can catch anything else. How about we target Monday week for releas=
e?

A 1.0.1 release should be driven by stability, not date, so we should see=
 if
any more issues come out of the woodwork.

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Friday, April 02, 2004 10:57 AM
Subject: [Springframework-developer] Preparing for 1.0.1


Hi everybody,

From my point of view, the code is ready for release 1.0.1. There were a
couple of bug fixes and minor enhancements since 1.0 final. The most
important fix is proper Hibernate/JTA resource management when flush fail=
s.
Enhancements include the introduction of the MessageCodesResolver interfa=
ce
in the validation package, and a more efficient internal implementation o=
f
AbstractMessageSource. See the changelog for details.

Please give the current CVS snapshot a try. There shouldn't be any issues=
,
as changes are minor and just affect specific functionality. I'd like to
target mid next week for the release, i.e. two weeks after 1.0 final. In =
the
meantime, the only thing I plan to address is the lack of remoting covera=
ge
in the reference docs. If anyone feels the need to improve other parts of
the docs, please do so till mid next week!

Juergen


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] RE: internationalizing bean properties

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

MessageCool. Let me know if I can help.
  ----- Original Message -----=20
  From: Keith Donald=20
  To: spr...@li...=20
  Sent: Thursday, April 01, 2004 8:15 PM
  Subject: [Springframework-developer] RE: internationalizing bean =
properties


  I got to thinking about this some more and I think there is a better =
way to support internationalization of bean property values---attributes =
metadata.

  For example, if I do this:

  /**
   * @@Translatable
   */
  public void setMyTranslatableProperty(String property);

  ... the bean post processor could notice the @@Translatable attribute =
and then know to load the string value from a message source, then set =
it.  I could also use introduction to attach internationalized =
"descriptor" classes (having stuff like name, caption, description) =
which are "common" properties needed when representing an object in a =
GUI (for the label, tooltip, and detailed description, for example.)

  IoC+AOP+Metadata is quite enabling! All kinds of stuff seems possible =
that just wasn't before.  Keith

   -----Original Message-----
  From: Keith Donald [mailto:kd...@cs...]=20
  Sent: Wednesday, March 31, 2004 5:42 PM
  To: 'spr...@li...'
  Subject: internationalizing bean properties


    For spring-rcp I have several bean declarations for configuring =
things like actions, menus, and such--- basically beans whose properties =
need internationalization.

    Wanted to make sure I am going about the best way of doing this:

    1. Initially, before adding internationalization support, I had =
these bean's localizable properties simply specified manually in the =
bean configuration xml.  Not good.

    Since I must provide internationalization of the GUI I've considered =
two options:
        - use a property placeholder configurer to inject localized =
property values from some properties file
        - use a bean post processor to retrieve localized =
properties/icons from message source and image source (before bean =
initialization)

    I've just implemented the latter, as it simplifies the XML code (I =
no longer have to specify values or variable names for the resolvable =
properties in xml) - the bean post processor attempts to resolve =
configuration values by checking to see if a bean implements a certain =
"DescriptionConfigurable" or "LabelConfigurable" or =
"ImageIconConfigurable" interface, for example.  The beanName is used as =
a prefix to the resolved message/image code.  So for example, for the =
"aboutAction" bean you'd see:

    messages_en.properties

    # LabelConfigurable interface: setLabel(LabelInfo)
    # (The '&' is the displayed mnemonic + index and the @ references =
the accelerator key - adapted from Eclipse's format.)
    aboutAction.label=3D&About @ CTRL-A

    # DescriptionConfigurable: setCaption(String) / =
setDescription(String)
    aboutAction.caption=3DDisplays an about dialog
    aboutAction.description=3DThe about action long description...

    images_en.properties

    # ImageIconConfigurable: setIcon(ImageIcon)
    aboutAction.icon=3Dcore/about.gif

    # ImageIconButtonConfigurable: rollover/pressed/disabled
    aboutAction.rolloverIcon=3D..
    aboutAction.pressedIcon=3D...
    aboutAction.disabledIcon...

    Seems like a pretty good approach, and simplifies the beans =
themselves a lot since they don't have to deal with message or image =
lookup.  Just wanted to post for comments and if there is anything I =
should be aware of... Keith

Re: [Springframework-developer] Preparing for 1.0.1

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

I've touched quite a lot of files in the aop package but mainly just =
applied minor polishing. I did a JDepend analysis and removed some =
cyclic dependencies beetwen aop subpackages, mainly affecting the use of =
AopConfigException and the location of AopUtils. The latter has moved, =
but it's considered an internal class, so this should be fine even for a =
point release (Rod takes this point of view too).
=20
Other changes include a more efficient AbstractMessageSource =
implementation, and the introduction of the MessageCodesResolver =
interface in the validation package. A further new feature that I'm =
gonna commit tomorrow is to allow for Ant-style patterns as =
"contextConfigLocation", for example "/WEB-INF/*-context.xml". This was =
pretty easy to add with out existing PathMatcher, which is currently =
used by the HandlerMapping implementations.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von tho...@tr...
Gesendet: Fr 02.04.2004 18:28
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



I noticed a lot of changes in CVS yesterday - any area in particular =
where we
should look out for problems?  My database product name caching fix is =
in CVS
now - so even if you don't preconfigure a JdbcTemlpate, you should now =
only see
one metadata lookup and the rest should be 'found in cache' entries in =
the log
(INFO).

Thomas


Quoting Colin Sampaleanu <col...@ex...>:

> I've been using the CVS version without issues.   I did some=3D20
> proofing/rewriting in the beans chapter earlier this week/last week, =
and=3D20
> should probably be able to find time to do the rest by the time you =
cut=3D20
> the release.
>
> j=3DFCrgen h=3DF6ller [werk3AT] wrote:
>
> >Hi everybody,
> >=3D20
> >From my point of view, the code is ready for release 1.0.1. There =
were a=3D
>  couple of bug fixes and minor enhancements since 1.0 final. The most =
imp=3D
> ortant fix is proper Hibernate/JTA resource management when flush =
fails. =3D
> Enhancements include the introduction of the MessageCodesResolver =
interfa=3D
> ce in the validation package, and a more efficient internal =
implementatio=3D
> n of AbstractMessageSource. See the changelog for details.
> >=3D20
> >Please give the current CVS snapshot a try. There shouldn't be any =
issue=3D
> s, as changes are minor and just affect specific functionality. I'd =
like =3D
> to target mid next week for the release, i.e. two weeks after 1.0 =
final. =3D
> In the meantime, the only thing I plan to address is the lack of =
remoting=3D
>  coverage in the reference docs. If anyone feels the need to improve =
othe=3D
> r parts of the docs, please do so till mid next week!
> >=3D20
> >Juergen
> > =3D20
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>





-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Preparing for 1.0.1

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

I noticed a lot of changes in CVS yesterday - any area in particular where we
should look out for problems?  My database product name caching fix is in CVS
now - so even if you don't preconfigure a JdbcTemlpate, you should now only see
one metadata lookup and the rest should be 'found in cache' entries in the log
(INFO).

Thomas


Quoting Colin Sampaleanu <col...@ex...>:

> I've been using the CVS version without issues.   I did some=20
> proofing/rewriting in the beans chapter earlier this week/last week, and=20
> should probably be able to find time to do the rest by the time you cut=20
> the release.
> 
> j=FCrgen h=F6ller [werk3AT] wrote:
> 
> >Hi everybody,
> >=20
> >From my point of view, the code is ready for release 1.0.1. There were a=
>  couple of bug fixes and minor enhancements since 1.0 final. The most imp=
> ortant fix is proper Hibernate/JTA resource management when flush fails. =
> Enhancements include the introduction of the MessageCodesResolver interfa=
> ce in the validation package, and a more efficient internal implementatio=
> n of AbstractMessageSource. See the changelog for details.
> >=20
> >Please give the current CVS snapshot a try. There shouldn't be any issue=
> s, as changes are minor and just affect specific functionality. I'd like =
> to target mid next week for the release, i.e. two weeks after 1.0 final. =
> In the meantime, the only thing I plan to address is the lack of remoting=
>  coverage in the reference docs. If anyone feels the need to improve othe=
> r parts of the docs, please do so till mid next week!
> >=20
> >Juergen
> > =20
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] Preparing for 1.0.1

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

I've been using the CVS version without issues.   I did some=20
proofing/rewriting in the beans chapter earlier this week/last week, and=20
should probably be able to find time to do the rest by the time you cut=20
the release.

j=FCrgen h=F6ller [werk3AT] wrote:

>Hi everybody,
>=20
>From my point of view, the code is ready for release 1.0.1. There were a=
 couple of bug fixes and minor enhancements since 1.0 final. The most imp=
ortant fix is proper Hibernate/JTA resource management when flush fails. =
Enhancements include the introduction of the MessageCodesResolver interfa=
ce in the validation package, and a more efficient internal implementatio=
n of AbstractMessageSource. See the changelog for details.
>=20
>Please give the current CVS snapshot a try. There shouldn't be any issue=
s, as changes are minor and just affect specific functionality. I'd like =
to target mid next week for the release, i.e. two weeks after 1.0 final. =
In the meantime, the only thing I plan to address is the lack of remoting=
 coverage in the reference docs. If anyone feels the need to improve othe=
r parts of the docs, please do so till mid next week!
>=20
>Juergen
> =20
>

[Springframework-developer] CGLIB proxies and fields

[Hunter K. <re...@ei...>]

[ This was already sent to the user list, it was suggested I send it on
to the developers list.]

There is some strange behaviour with CGLIB proxied objects and instance 
fields.  Sometime it returns the field of the CGLIB proxy itself, and 
sometimes of the target object, which causes some very unexpected behaviour, 
to say the least.

This is similar to the thread of yesterday, but it petered out somewhat 
inconclusively.  I've boiled it down to a pretty simple sample.

The results are as follows (skipping the initial spring setup stuff):

INFO: Creating implicit proxy for bean 'sampleCommand' with 1 common 
interceptors and 0 specific interceptors
02-Apr-2004 10:45:22 
org.springframework.transaction.support.AbstractPlatformTransactionManager 
commit
INFO: Initiating transaction commit
returned result: <no result>
02-Apr-2004 10:45:22 
org.springframework.transaction.support.AbstractPlatformTransactionManager 
commit
INFO: Initiating transaction commit
method call result: RealCommand result: 3
direct method call result: RealCommand result: 3


Here's the java class and the config file.  The only thing that anyone should
need to change is the properties of the data source...

-- SampleCommand.java

package sample;

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class SampleCommand
{
    public static final ApplicationContext appContext = 
initializeAppContext();
    
     private static ApplicationContext initializeAppContext()
     {
         ClassPathXmlApplicationContext ctx = new 
ClassPathXmlApplicationContext("sampleContext.xml");
         return ctx;
     }

    String _result = "<no result>";
    
    public final String execute()
    {
        executeCommand();
        return _result;
    }
    
    public final String executeUsingMethod()
    {
        executeCommand();
        return getResult();
    }

    public String getResult()
    {
        return _result;
    }

    int _foo;
    public void setFoo(int foo)
    { 
        _foo = foo;
    }
    
    public void executeCommand()
    {
        _result = "RealCommand result: "+_foo;
    }
    
    public static  void main(String[] args)
    {
        SampleCommand c = (SampleCommand) appContext.getBean("sampleCommand");
        c.setFoo(3);
        System.out.println("returned result: "+c.execute());
        System.out.println("method call result: "+c.executeUsingMethod());
        System.out.println("direct method call result: "+c.getResult());
    }
}

-- sampleContext.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" 
"http://www.springframework.org/dtd/spring-beans.dtd">
<beans>

	<bean id="sampleCommand" class="sample.SampleCommand"/>

    <!-- Transaction Interceptor set up to do PROPAGATION_REQUIRED on execute 
methods  for Command objects-->
	<bean id="executeMethodTxnAS" 
class="org.springframework.transaction.interceptor.NameMatchTransactionAttributeSource">
	    <property name="properties">
	    	<props>
	    		<prop key="execute*">PROPAGATION_REQUIRED</prop>
	    	</props>
	    </property>
	</bean>
  	
	<bean id="commandExecuteMethodTxnInterceptor" 
class="org.springframework.transaction.interceptor.TransactionInterceptor">
    	<property name="transactionManager"><ref 
local="transactionManager"/></property>
    	<property name="transactionAttributeSource">
    		<!-- I think this uses the spiffy TransactionAttributeSourceEditor, 
obviating the need for a seperate 
    		       TransactionAttributeSource definition in simple cases -->
    		<!-- 
value>com.newbay.mixxe.command.Command.execute=PROPAGATION_REQUIRED</value 
-->
    		<ref local="executeMethodTxnAS"/>
    	</property>
	</bean>

	<!-- One BeanNameAutoProxyCreator handles all beans where we want 
transactions (ie Command.execute) -->
	<bean id="autoProxyCreator" 
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
	    <property name="interceptorNames">
    		<list><idref local="commandExecuteMethodTxnInterceptor"/></list>
	    </property>
	    <property name="proxyTargetClass"><value>true</value></property>
	    <!-- property name="exposeProxy"><value>true</value></property -->
    	<property name="beanNames">
      		<list><value>*Command</value></list>
	    </property>
  	</bean>
	
	<bean id="transactionManager" 
class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
		<property name="dataSource"><ref local="dataSource"/></property>
	</bean>
	
	<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" 
destroy-method="close">
		<property 
name="driverClassName"><value>org.postgresql.Driver</value></property>
		<property 
name="url"><value>jdbc:postgresql://localhost/mixxe</value></property>
		<property name="username"><value>mixxe</value></property>
		<property name="password"><value>mixxe</value></property>
	</bean>
	
	
	
</beans>	

    
     

[Springframework-developer] Preparing for 1.0.1

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

Hi everybody,
=20
From my point of view, the code is ready for release 1.0.1. There were a =
couple of bug fixes and minor enhancements since 1.0 final. The most =
important fix is proper Hibernate/JTA resource management when flush =
fails. Enhancements include the introduction of the MessageCodesResolver =
interface in the validation package, and a more efficient internal =
implementation of AbstractMessageSource. See the changelog for details.
=20
Please give the current CVS snapshot a try. There shouldn't be any =
issues, as changes are minor and just affect specific functionality. I'd =
like to target mid next week for the release, i.e. two weeks after 1.0 =
final. In the meantime, the only thing I plan to address is the lack of =
remoting coverage in the reference docs. If anyone feels the need to =
improve other parts of the docs, please do so till mid next week!
=20
Juergen

[Springframework-developer] Sandbox build files

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

Do we have build files for the sandbox? Or am I blind ;-).

 

I we don't, I just added build-sandbox and tests-sandbox targets so if we
need them in CVS.

 

Alef

 

 

 

==
JTeam B.V.
Donker Curtiusstraat 7-412
1051 JL  Amsterdam
T: +31 20 486 20 36
M: +31 6 24 11 1996
F: +31 84 837 00 00
E: al...@jt...
W: http://www.jteam.nl