springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Attributes

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

Rod,

Is this an older version of the attributes code? The dep info at Apache 
lists qdox:
  http://jakarta.apache.org/commons/sandbox/attributes/dependencies.html


Rod Johnson wrote:

>The tests now depend on a Commons Attributes precompile step. However, this
>doesn't take very long at all as it applies only to one package.
>
>However, you will need to put the following files in your $ANT_HOME/lib to
>get the tests to run:
>
>- Commons Attributes compiler Jar (in CVS)
>- commons-collections.jar (in CVS)
>- xjavadoc.jar (from XDoclet project). I'm not sure whether to put this in
>CVS as none of our code uses it. Thoughts?
>
>For now, I've named the attributes-dependent test case so that Eclipse won't
>pick up. I'll change this when I get time so that the build is also
>triggered under Eclipse.
>
>Regards,
>Rod
>  
>

[Springframework-developer] Attributes

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

The tests now depend on a Commons Attributes precompile step. However, this
doesn't take very long at all as it applies only to one package.

However, you will need to put the following files in your $ANT_HOME/lib to
get the tests to run:

- Commons Attributes compiler Jar (in CVS)
- commons-collections.jar (in CVS)
- xjavadoc.jar (from XDoclet project). I'm not sure whether to put this in
CVS as none of our code uses it. Thoughts?

For now, I've named the attributes-dependent test case so that Eclipse won't
pick up. I'll change this when I get time so that the build is also
triggered under Eclipse.

Regards,
Rod

____________________________________________________
Rod Johnson
J2EE Consultant and Author
+44 7973 409 132
rod...@in...

Author of "Expert One-on-One J2EE Design and Development"
(October 2002).
http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/

Founder, Spring Framework:
http://www.springframework.org

"Introducing the Spring Framework" (ServerSide article)
http://www.theserverside.com/resources/article.jsp?l=SpringFramework

Re: [Springframework-developer] Eclipse build broken

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

Colin,

Thanks for fixing the Eclipse path--Juergen did the Velocity changes, but
for some reason I seem to have a blind spot when I change the Eclipse
classpath myself.

We mainly want those broken files in the sandbox for the history. I'll
probably just comment the content out.

The reason that we now depend on Commons Attributes is that we now have a
simple facade interface (org.springframework.metadata.Attributes) behind
which we can have pluggable attributes implementations (including our own
post 1.0, and JSR-175). I've now implemented this interface for Commons
Attributes.

This is now used as the basis of .NET-style attribute-driven transaction
management and pooling as I've wanted for quite a while, and like the old
"enterprise services" package, which is now gone from the sandbox.

See the attached file for an example. The build script and XML bean
definitions in that package in the test tree illustrate how Commons
Attributes is used to compile the sources, and how AOP autoproxying is
configured to do this.

I'll make a post to describe this functionality properly later this week--I
think it's quite important. The attribute-driven layer over our generic AOP
autoproxying support (now in org.springframework.aop.autoproxy) is very
thin.

Regards,
Rod

----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Monday, December 15, 2003 4:02 AM
Subject: Re: [Springframework-developer] Eclipse build broken


> As per my other emails, I haven't gotten any emails on the list over the
> weekends, so I don't know what people are workin on, but I guess the
> Eclipse breakage is probably from one of the non-Eclipse guys (Juergen?).
>
> I've added back in a link to velocity 1.3.1 and the velocity tools. I
> also added in a link to the common-attributes, which seems to be needed
now.
>
> At this point all is ok except for some sandbox code, which still has
> errors, BCELAttributes, PersonJava, AttributesWriterTests, and
> CompilerTests.  I am not attempting to fix those since I don't know what
> the intent is. As per discussion last week, they are going away, and I
> think Rod or somebody just accidentally left them in...
>
>
> Cameron Braid wrote:
>
> > The .classpath points to an non existant velocity-1.3.jar... there is
> > a velocity-1.3.1.jar there, which even after changing to, doesn't fix
> > all classpath errors.
> >
> > Cameron
> >
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Refreshing the ApplicationContext...

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

Hi Ross,
=20
"refresh" is now in ConfigurableApplicationContext, but you shouldn't =
need that for typical usages anyway. I guess what you're trying to do is =
custom initialization of the root WebApplicationContext, storing it in a =
custom place via the setApplicationContext call. That should be fine: I =
suppose that the error you're getting has other origins. Autowiring has =
been significantly reworked; could you check for which components you =
get more than one matching bean? The reason could be that you actually =
*have* multiple matching beans, which just weren't found by M2's =
autowire implementation, maybe due to being created by FactoryBeans. =
Could you quote relevant parts of your configuration?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Ross Mason
Gesendet: Mo 15.12.2003 07:50
An: spr...@li...
Betreff: [Springframework-developer] Refreshing the =
ApplicationContext...



Hi,

In the latest source the ApplicationContext.refresh() method has been
removed.  What is the recommended way of refreshing an
applicationContext now. I'm trying -

         ContextLoader loader =3D new ContextLoader();
         setApplicationContext(
loader.initWebApplicationContext(servletContext) );

But I am getting an error saying that there is more than one matching
bean on some components when autoWiring by type.  Our code and cofig
works fine with M2 release, but we're mored to the latest source to make
use of the OpenSessionInViewFilter.

Any ideas?


Cheers,

Ross



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Refreshing the ApplicationContext...

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

Hi,

In the latest source the ApplicationContext.refresh() method has been 
removed.  What is the recommended way of refreshing an 
applicationContext now. I'm trying -

         ContextLoader loader = new ContextLoader();
         setApplicationContext( 
loader.initWebApplicationContext(servletContext) );

But I am getting an error saying that there is more than one matching 
bean on some components when autoWiring by type.  Our code and cofig 
works fine with M2 release, but we're mored to the latest source to make 
use of the OpenSessionInViewFilter.

Any ideas?


Cheers,

Ross

[Springframework-developer] Building source

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

Hi,

You need to add the commons-attributes dependency to your project.xml 
and the jar to your distribution.

Cheers,

Ross

Re: [Springframework-developer] Eclipse build broken

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

Thankyou for the prompt reply.

Most appreciated.

Cameron

Colin Sampaleanu wrote:

> As per my other emails, I haven't gotten any emails on the list over 
> the weekends, so I don't know what people are workin on, but I guess 
> the Eclipse breakage is probably from one of the non-Eclipse guys 
> (Juergen?).
>
> I've added back in a link to velocity 1.3.1 and the velocity tools. I 
> also added in a link to the common-attributes, which seems to be 
> needed now.
>
> At this point all is ok except for some sandbox code, which still has 
> errors, BCELAttributes, PersonJava, AttributesWriterTests, and 
> CompilerTests.  I am not attempting to fix those since I don't know 
> what the intent is. As per discussion last week, they are going away, 
> and I think Rod or somebody just accidentally left them in...
>
>
> Cameron Braid wrote:
>
>> The .classpath points to an non existant velocity-1.3.jar... there is 
>> a velocity-1.3.1.jar there, which even after changing to, doesn't fix 
>> all classpath errors.
>>
>> Cameron
>>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>


-- 
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf]

Re: [Springframework-developer] Eclipse build broken

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

As per my other emails, I haven't gotten any emails on the list over the 
weekends, so I don't know what people are workin on, but I guess the 
Eclipse breakage is probably from one of the non-Eclipse guys (Juergen?).

I've added back in a link to velocity 1.3.1 and the velocity tools. I 
also added in a link to the common-attributes, which seems to be needed now.

At this point all is ok except for some sandbox code, which still has 
errors, BCELAttributes, PersonJava, AttributesWriterTests, and 
CompilerTests.  I am not attempting to fix those since I don't know what 
the intent is. As per discussion last week, they are going away, and I 
think Rod or somebody just accidentally left them in...


Cameron Braid wrote:

> The .classpath points to an non existant velocity-1.3.jar... there is 
> a velocity-1.3.1.jar there, which even after changing to, doesn't fix 
> all classpath errors.
>
> Cameron
>

Re: [Springframework-developer] What's happened to the mail archives?

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

Nope, so if you can see messages something weird is going on. In the dev 
list, the last message before mine popped in is from Darren on Fri. 
night at 8:33. In the SourceForge archives for the dev list, the last 
message I see is from Dec. 1st... In the user list, there was a message 
from Patrick Burleson on Fri. night, and one empty message today from 
Antony Josph, at 5:14. As for the archives, Dec. 1st again

Given the fact that my messages and the replies to them showed up, if 
you really got other messages in between, and can also see them on SF, 
the only thing I can think of is that different parts of SourceForge are 
handling mail for us...


Ross Mason wrote:

> There were plenty of posts over the weekend... and I can see them on 
> sf.  Can you see them now?
>
> Ross
>
> Colin Sampaleanu wrote:
>
>> Patrick Burleson wrote:
>>
>>> Colin Sampaleanu wrote:
>>>
>>>> They seem to stop at Dec. 1...
>>>>
>>>> http://sourceforge.net/mailarchive/forum.php?forum_id=28401
>>>> http://sourceforge.net/mailarchive/forum.php?forum_id=30287
>>>>
>>>
>>> I think for some reason the archives are a few days behind. I am 
>>> wonder what happended to the lists in general. I haven't gotten a 
>>> message on the user list in a few days.
>>>
>> I think simply nobody posted. People generally have less spare time 
>> at this time of year...
>>

Re: [Springframework-developer] What's happened to the mail archives?

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

There were plenty of posts over the weekend... and I can see them on sf. 
  Can you see them now?

Ross

Colin Sampaleanu wrote:

> Patrick Burleson wrote:
> 
>> Colin Sampaleanu wrote:
>>
>>> They seem to stop at Dec. 1...
>>>
>>> http://sourceforge.net/mailarchive/forum.php?forum_id=28401
>>> http://sourceforge.net/mailarchive/forum.php?forum_id=30287
>>>
>>
>> I think for some reason the archives are a few days behind. I am 
>> wonder what happended to the lists in general. I haven't gotten a 
>> message on the user list in a few days.
>>
> I think simply nobody posted. People generally have less spare time at 
> this time of year...
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

[Springframework-developer] Eclipse build broken

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

The .classpath points to an non existant velocity-1.3.jar... there is a 
velocity-1.3.1.jar there, which even after changing to, doesn't fix all 
classpath errors.

Cameron

-- 
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf]

Re: [Springframework-developer] What's happened to the mail archives?

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

Patrick Burleson wrote:

> Colin Sampaleanu wrote:
>
>> They seem to stop at Dec. 1...
>>
>> http://sourceforge.net/mailarchive/forum.php?forum_id=28401
>> http://sourceforge.net/mailarchive/forum.php?forum_id=30287
>>
>
> I think for some reason the archives are a few days behind. I am 
> wonder what happended to the lists in general. I haven't gotten a 
> message on the user list in a few days.
>
I think simply nobody posted. People generally have less spare time at 
this time of year...

Re: [Springframework-developer] What's happened to the mail archives?

[Patrick B. <spr...@pa...>]

Colin Sampaleanu wrote:
> They seem to stop at Dec. 1...
> 
> http://sourceforge.net/mailarchive/forum.php?forum_id=28401
> http://sourceforge.net/mailarchive/forum.php?forum_id=30287
> 

I think for some reason the archives are a few days behind. I am wonder 
what happended to the lists in general. I haven't gotten a message on 
the user list in a few days.

Thanks,
Patrick

[Springframework-developer] What's happened to the mail archives?

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

They seem to stop at Dec. 1...

http://sourceforge.net/mailarchive/forum.php?forum_id=28401
http://sourceforge.net/mailarchive/forum.php?forum_id=30287

Re: [Springframework-developer] VelocityView

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

On Saturday 13 December 2003 00:30, j=FCrgen h=F6ller [werk3AT] wrote:

> In the current Velocity Tools 1.1 dev version, they've introduced an
> analogous "NumberTool" class, supporting all kinds of number formatting
> options. I intend to support that too via a "numberToolAttribute", as
> soon as it's released in a beta. If something's missing, we should tell
> the Velocity Tools team: I consider it preferable to use the "official"
> helpers that they develop instead of creating our ownl

agreed.

> Darren, and of course other Spring/Velocity users, could you please give
> the reworked stuff a try before the 1.0 M4 release? I consider it cleaner
> than before -- after all, we will need to support what we release as 1.0
> final for quite some time to come --, so I hope that you don't mind the
> changes.

will do.

=2D-=20

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

Re: [Springframework-developer] VelocityView

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

+1. I did actually consider using a velocity package for this, but there =
was
no download of that back when I wrote the first version of the Velocity
support last year.

----- Original Message -----=20
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>;
<spr...@li...>
Sent: Saturday, December 13, 2003 12:30 AM
Subject: Re: [Springframework-developer] VelocityView


I've thought about this for quite a while from various angles, and have c=
ome
to the conclusion that no such exposing of pre-defined DateFormats or
NumberFormats will be flexible enough: There are simply too many options =
to
generate instances, with DateFormat.LONG/SHORT,
getNumberInstance/getPercentInstance, etc. Any choice of pre-defined
formatters will be arbitrary. Thus, I've removed the whole DateFormat and
NumberFormat support from VelocityView. Whoever needs to expose such thin=
gs,
please override VelocityView's "exposeHelpers" method and expose formatte=
r
objects in just the way you need them.

As an alternative, I've integrated support for Velocity Tools, the extra
download from the Velocity team offered since this summer. Velocity Tools
features a "DateTool" class that is exactly targetted at our use case:
formatting dates in Velocity templates. Our VelocityView has a
"dateToolAttribute" property now, taking the name under which to expose a
DateTool instance, if desired. VelocityView will actually expose a DateTo=
ol
subclass that is aware of Spring's locale.

In the current Velocity Tools 1.1 dev version, they've introduced an
analogous "NumberTool" class, supporting all kinds of number formatting
options. I intend to support that too via a "numberToolAttribute", as soo=
n
as it's released in a beta. If something's missing, we should tell the
Velocity Tools team: I consider it preferable to use the "official" helpe=
rs
that they develop instead of creating our ownl

I've also revised VelocityEngineFactory and VelocityConfigurer in one
specific point: Although I've introduced the "appRootMarker" mechanism th=
ere
myself to allow for a resource loader path relative to the application
context, I've never been happy with it. That mechanism is suitable for Lo=
g4J
but not really for a context-managed bean. Thus, I've replaced it with a
"resourceLoaderPath" bean property on VelocityEngineFactory: Specifying t=
his
will automatically set the corresponding Velocity property
"file.resource.loader.path" with the given path appended to the
ApplicationContext's resource base.

Setting up a VelocityConfigurer for typical web usage is now even simpler
than before, as you just need to specify a "resourceLoaderPath", and just
optionally some other Velocity properties:

 <bean id=3D"velocityConfig"
class=3D"org.springframework.web.servlet.view.velocity.VelocityConfigurer=
">
  <property
name=3D"resourceLoaderPath"><value>/WEB-INF/velocity/</value></property>
 </bean>

Darren, and of course other Spring/Velocity users, could you please give =
the
reworked stuff a try before the 1.0 M4 release? I consider it cleaner tha=
n
before -- after all, we will need to support what we release as 1.0 final
for quite some time to come --, so I hope that you don't mind the changes.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Darren Davison
Gesendet: Fr 12.12.2003 10:07
An: spr...@li...
Betreff: Re: [Springframework-developer] VelocityView




> Similarly, VelocityView could have "dateFormatAttribute" and
> "currencyFormatAttribute" properties to allow for specifying the
> names of those attributes, instead of fixed names and boolean
> "exposeDateFormatter" respectively "exposeCurrencyFormatter" flags.
> We could also add an additional "numberFormatAttribute" property,
>  for a plain NumberFormat instance.
>
> Alternatively, we could also scrap the helper exposure altogether
> and leave that to subclasses, or find some way to associate such
> model objects as static attributes - maybe via AbstractView's
> "attributesMap" that can take bean references too? The latter would
> involve setting up DateFormat and NumberFormat instances as beans,
> linking them in as model attributes via bean references.
>
> After all, Velocity should really support such formatting itself -
> it is really weak in that respect. The JSTL's "fmt" tag library does
> that in a nice way for JSPs... Why does it have to be so complicated
> with Velocity? Finally, how are VelocityView users doing this
> currently? Is anyone using our exposure of pre-defined helpers or do
> you use your own mechanisms?

we're using the date format helper, simply because it was there - I'm not
particularly precious about it.  Supplying the helpers as beans defined i=
n a
context seems the more 'Spring-centric' way to go, however the helpers
currently use static factory methods that take a locale parameter from th=
e
current request - can that still be handled?

As long as there's no loss of functionality, I'm +1 for anything!



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


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] VelocityView

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

I've thought about this for quite a while from various angles, and have =
come to the conclusion that no such exposing of pre-defined DateFormats =
or NumberFormats will be flexible enough: There are simply too many =
options to generate instances, with DateFormat.LONG/SHORT, =
getNumberInstance/getPercentInstance, etc. Any choice of pre-defined =
formatters will be arbitrary. Thus, I've removed the whole DateFormat =
and NumberFormat support from VelocityView. Whoever needs to expose such =
things, please override VelocityView's "exposeHelpers" method and expose =
formatter objects in just the way you need them.
=20
As an alternative, I've integrated support for Velocity Tools, the extra =
download from the Velocity team offered since this summer. Velocity =
Tools features a "DateTool" class that is exactly targetted at our use =
case: formatting dates in Velocity templates. Our VelocityView has a =
"dateToolAttribute" property now, taking the name under which to expose =
a DateTool instance, if desired. VelocityView will actually expose a =
DateTool subclass that is aware of Spring's locale.
=20
In the current Velocity Tools 1.1 dev version, they've introduced an =
analogous "NumberTool" class, supporting all kinds of number formatting =
options. I intend to support that too via a "numberToolAttribute", as =
soon as it's released in a beta. If something's missing, we should tell =
the Velocity Tools team: I consider it preferable to use the "official" =
helpers that they develop instead of creating our ownl
=20
I've also revised VelocityEngineFactory and VelocityConfigurer in one =
specific point: Although I've introduced the "appRootMarker" mechanism =
there myself to allow for a resource loader path relative to the =
application context, I've never been happy with it. That mechanism is =
suitable for Log4J but not really for a context-managed bean. Thus, I've =
replaced it with a "resourceLoaderPath" bean property on =
VelocityEngineFactory: Specifying this will automatically set the =
corresponding Velocity property "file.resource.loader.path" with the =
given path appended to the ApplicationContext's resource base.
=20
Setting up a VelocityConfigurer for typical web usage is now even =
simpler than before, as you just need to specify a "resourceLoaderPath", =
and just optionally some other Velocity properties:
=20
 <bean id=3D"velocityConfig" =
class=3D"org.springframework.web.servlet.view.velocity.VelocityConfigurer=
">
  <property =
name=3D"resourceLoaderPath"><value>/WEB-INF/velocity/</value></property>
 </bean>

Darren, and of course other Spring/Velocity users, could you please give =
the reworked stuff a try before the 1.0 M4 release? I consider it =
cleaner than before -- after all, we will need to support what we =
release as 1.0 final for quite some time to come --, so I hope that you =
don't mind the changes.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Darren Davison
Gesendet: Fr 12.12.2003 10:07
An: spr...@li...
Betreff: Re: [Springframework-developer] VelocityView




> Similarly, VelocityView could have "dateFormatAttribute" and
> "currencyFormatAttribute" properties to allow for specifying the
> names of those attributes, instead of fixed names and boolean
> "exposeDateFormatter" respectively "exposeCurrencyFormatter" flags.
> We could also add an additional "numberFormatAttribute" property,
>  for a plain NumberFormat instance.
>
> Alternatively, we could also scrap the helper exposure altogether
> and leave that to subclasses, or find some way to associate such
> model objects as static attributes - maybe via AbstractView's
> "attributesMap" that can take bean references too? The latter would
> involve setting up DateFormat and NumberFormat instances as beans,
> linking them in as model attributes via bean references.
>
> After all, Velocity should really support such formatting itself -
> it is really weak in that respect. The JSTL's "fmt" tag library does
> that in a nice way for JSPs... Why does it have to be so complicated
> with Velocity? Finally, how are VelocityView users doing this
> currently? Is anyone using our exposure of pre-defined helpers or do
> you use your own mechanisms?

we're using the date format helper, simply because it was there - I'm =
not
particularly precious about it.  Supplying the helpers as beans defined =
in a
context seems the more 'Spring-centric' way to go, however the helpers
currently use static factory methods that take a locale parameter from =
the
current request - can that still be handled?

As long as there's no loss of functionality, I'm +1 for anything!



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


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Fw: [springframework - Help] Building Spring from source

[Luke T. <lu...@mo...>]

Hi all,

A few things to follow up.

1. Anyone else can add themselves to the developers list in the 
project.xml, then their full names will appear in the report.

2. I'll try and update the clover jar (though it looks like an older 
version than the current one used by the maven plugin) and look at 
modifying the styles to match the main logo.

3. The "about" text can be switched to anything and will currently just 
be the description in the project.xml. Feel free to change it. I had a 
skeleton set of xdocs files in CVS a while back but they're not there 
anymore. It's probably best just to keep producing the reports from the 
maven build and link back to the main site

4. The XML parser issue cropped up a while back - I think it's a crimson 
vs xerces thing. Building with ant you're using xerces. I can probably 
switch Maven to use xerces too. Does someone know what the problem is? 
Will it cause issues with using the framework with another parser?

5. No cheating by doing extra commits to get to the top of the list :-).

6. Anyone got any useful tips on setting up a continuous 
integration/build system? The reports aren't going to be much use unless 
they're current.

7. To stop the build breaking, it would be very useful if people could 
update the dependencies in the project.xml file when jars are added or 
updated. E.g. for the new velocity stuff:

       <dependency>
          <id>velocity</id>
          <version>1.3.1</version>
       </dependency>
       <dependency>
          <groupId>velocity-tools</groupId>
          <artifactId>velocity-tools-generic</artifactId>
          <version>1.0</version>
       </dependency>

You can check whether they're available at ibiblio 
(http://www.ibiblio.org/maven). If not then you can override the 
versions in the project.properties files and make them point to the jars 
in the Spring lib directory.

I've started using Spring code this past couple of weeks with a client 
and things are looking pretty impressive. Congratulations on doing such 
a great job. I'm looking forward to getting time to get my head round 
what's been going on for the past year.

All the best,

Luke.


Rod Johnson wrote:
> Luke,
> 
> The Maven site is looking pretty good now! Well done. I think we should link
> to it from the home page in the not too distant future. Just a few things
> still to iron out.
> 
> A few notes:
> 
> - maybe the "about" text could come from the web site.
> - the unit test failures look like an XML parser issue. A conflict with
> Maven perhaps?
> - Thomas, what would be the best logo to use? Maybe the Jira one would work
> for top left?
> - We have a licensed copy of Clover in CVS. If you use that Jar you will get
> a nice message saying it's licensed for the Spring Framework.
> - damn, one of my most active periods for months and I still haven't caught
> up with Juergen's number of commits!
> 




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

Re: [Springframework-developer] Fw: [springframework - Help] Building Spring from source

[<tri...@tr...>]

I have two more:

http://www.springframework.org/images/spring_large_logo.gif

http://www.springframework.org/images/spring_small_logo.gif

Thomas


Quoting tri...@tr...:

> Would this logo work?
> 
> http://www.springframework.org/images/spring_maven_logo.gif
> 
> Thomas
> 
> Quoting Rod Johnson <rod...@in...>:
> 
> > Luke,
> > 
> > The Maven site is looking pretty good now! Well done. I think we should
> link
> > to it from the home page in the not too distant future. Just a few things
> > still to iron out.
> > 
> > A few notes:
> > 
> > - maybe the "about" text could come from the web site.
> > - the unit test failures look like an XML parser issue. A conflict with
> > Maven perhaps?
> > - Thomas, what would be the best logo to use? Maybe the Jira one would
> work
> > for top left?
> > - We have a licensed copy of Clover in CVS. If you use that Jar you will
> get
> > a nice message saying it's licensed for the Spring Framework.
> > - damn, one of my most active periods for months and I still haven't
> caught
> > up with Juergen's number of commits!
> > 
> > Regards,
> > Rod
> > 
> > ----- Original Message ----- 
> > From: "Luke Taylor" <ne...@fr...>
> > To: <spr...@li...>
> > Sent: Friday, December 12, 2003 7:00 PM
> > Subject: Re: [Springframework-developer] Fw: [springframework - Help]
> > Building Spring from source
> > 
> > 
> > > On the build front, I updated the Maven build so that it should work out
> > > of the box with Maven-rc1. I've tried it on a new Linux server without
> > > any problems. As before the site is
> > >
> > > http://www.monkeymachine.co.uk/spring
> > >
> > > and the project reports are the interesting bit. I also hope to set up a
> > > daily build in the near future as I want to do this for a client anyway.
> > > So I hope that'll be of some use as a reference.
> > >
> > > One of the other benefits of a build with Maven is that you don't need
> > > the binaries (apart from those which aren't available from
> > > www.ibiblio.org/maven, which I've overriden in the project.properties
> > > file to point to the local versions).
> > >
> > > Rod Johnson wrote:
> > >
> > > > We definitely need the build script and properties in the release too,
> > even
> > > > if we don't ship all the binaries.
> > > >
> > >
> > >
> > > -- 
> > >   Luke Taylor.                      Monkey Machine Ltd.
> > >   PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: IBM Linux Tutorials.
> > > Become an expert in LINUX or just sharpen your skills.  Sign up for
> IBM's
> > > Free Linux Tutorials.  Learn everything from the bash shell to sys
> admin.
> > > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&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.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&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.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] Fw: [springframework - Help] Building Spring from source

[<tri...@tr...>]

Would this logo work?

http://www.springframework.org/images/spring_maven_logo.gif

Thomas

Quoting Rod Johnson <rod...@in...>:

> Luke,
> 
> The Maven site is looking pretty good now! Well done. I think we should link
> to it from the home page in the not too distant future. Just a few things
> still to iron out.
> 
> A few notes:
> 
> - maybe the "about" text could come from the web site.
> - the unit test failures look like an XML parser issue. A conflict with
> Maven perhaps?
> - Thomas, what would be the best logo to use? Maybe the Jira one would work
> for top left?
> - We have a licensed copy of Clover in CVS. If you use that Jar you will get
> a nice message saying it's licensed for the Spring Framework.
> - damn, one of my most active periods for months and I still haven't caught
> up with Juergen's number of commits!
> 
> Regards,
> Rod
> 
> ----- Original Message ----- 
> From: "Luke Taylor" <ne...@fr...>
> To: <spr...@li...>
> Sent: Friday, December 12, 2003 7:00 PM
> Subject: Re: [Springframework-developer] Fw: [springframework - Help]
> Building Spring from source
> 
> 
> > On the build front, I updated the Maven build so that it should work out
> > of the box with Maven-rc1. I've tried it on a new Linux server without
> > any problems. As before the site is
> >
> > http://www.monkeymachine.co.uk/spring
> >
> > and the project reports are the interesting bit. I also hope to set up a
> > daily build in the near future as I want to do this for a client anyway.
> > So I hope that'll be of some use as a reference.
> >
> > One of the other benefits of a build with Maven is that you don't need
> > the binaries (apart from those which aren't available from
> > www.ibiblio.org/maven, which I've overriden in the project.properties
> > file to point to the local versions).
> >
> > Rod Johnson wrote:
> >
> > > We definitely need the build script and properties in the release too,
> even
> > > if we don't ship all the binaries.
> > >
> >
> >
> > -- 
> >   Luke Taylor.                      Monkey Machine Ltd.
> >   PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&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.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] Fw: [springframework - Help] Building Spring from source

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

Luke,

The Maven site is looking pretty good now! Well done. I think we should link
to it from the home page in the not too distant future. Just a few things
still to iron out.

A few notes:

- maybe the "about" text could come from the web site.
- the unit test failures look like an XML parser issue. A conflict with
Maven perhaps?
- Thomas, what would be the best logo to use? Maybe the Jira one would work
for top left?
- We have a licensed copy of Clover in CVS. If you use that Jar you will get
a nice message saying it's licensed for the Spring Framework.
- damn, one of my most active periods for months and I still haven't caught
up with Juergen's number of commits!

Regards,
Rod

----- Original Message ----- 
From: "Luke Taylor" <ne...@fr...>
To: <spr...@li...>
Sent: Friday, December 12, 2003 7:00 PM
Subject: Re: [Springframework-developer] Fw: [springframework - Help]
Building Spring from source


> On the build front, I updated the Maven build so that it should work out
> of the box with Maven-rc1. I've tried it on a new Linux server without
> any problems. As before the site is
>
> http://www.monkeymachine.co.uk/spring
>
> and the project reports are the interesting bit. I also hope to set up a
> daily build in the near future as I want to do this for a client anyway.
> So I hope that'll be of some use as a reference.
>
> One of the other benefits of a build with Maven is that you don't need
> the binaries (apart from those which aren't available from
> www.ibiblio.org/maven, which I've overriden in the project.properties
> file to point to the local versions).
>
> Rod Johnson wrote:
>
> > We definitely need the build script and properties in the release too,
even
> > if we don't ship all the binaries.
> >
>
>
> -- 
>   Luke Taylor.                      Monkey Machine Ltd.
>   PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Fw: [springframework - Help] Building Spring from source

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

My commits and Darren's at least seem to be reported actually (obviously 
there are not that many of them compared to the torrent from Juergen and 
Rod through :-) ).
   http://www.monkeymachine.co.uk/spring/changelog-report.html
Usernames are 'colins' and ' davison'. I don't know why others show with 
the full names, and we show as only the cvs usernames. Possibly it's 
because we are not listed in the maven POM as developers. That's easy to 
fix though...


tri...@tr... wrote:

>Luke,
>
>This is a good project overview, but somehow Mark's, Darren's and Colin's CVS
>commits are not reflected in the reports.  I think your developer list need to
>be updated.
>
>Thomas
>
>Quoting Luke Taylor <ne...@fr...>:
>
>  
>
>>On the build front, I updated the Maven build so that it should work out 
>>of the box with Maven-rc1. I've tried it on a new Linux server without 
>>any problems. As before the site is
>>
>>http://www.monkeymachine.co.uk/spring
>>
>>and the project reports are the interesting bit. I also hope to set up a 
>>daily build in the near future as I want to do this for a client anyway. 
>>So I hope that'll be of some use as a reference.
>>
>>One of the other benefits of a build with Maven is that you don't need 
>>the binaries (apart from those which aren't available from 
>>www.ibiblio.org/maven, which I've overriden in the project.properties 
>>file to point to the local versions).
>>
>>Rod Johnson wrote:
>>
>>    
>>
>>>We definitely need the build script and properties in the release too,
>>>      
>>>
>>even
>>    
>>
>>>if we don't ship all the binaries.
>>>
>>>      
>>>
>>-- 
>>  Luke Taylor.                      Monkey Machine Ltd.
>>  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk
>>
>>    
>>

Re: [Springframework-developer] Fw: [springframework - Help] Building Spring from source

[<tri...@tr...>]

Luke,

This is a good project overview, but somehow Mark's, Darren's and Colin's CVS
commits are not reflected in the reports.  I think your developer list need to
be updated.

Thomas

Quoting Luke Taylor <ne...@fr...>:

> On the build front, I updated the Maven build so that it should work out 
> of the box with Maven-rc1. I've tried it on a new Linux server without 
> any problems. As before the site is
> 
> http://www.monkeymachine.co.uk/spring
> 
> and the project reports are the interesting bit. I also hope to set up a 
> daily build in the near future as I want to do this for a client anyway. 
> So I hope that'll be of some use as a reference.
> 
> One of the other benefits of a build with Maven is that you don't need 
> the binaries (apart from those which aren't available from 
> www.ibiblio.org/maven, which I've overriden in the project.properties 
> file to point to the local versions).
> 
> Rod Johnson wrote:
> 
> > We definitely need the build script and properties in the release too,
> even
> > if we don't ship all the binaries.
> > 
> 
> 
> -- 
>   Luke Taylor.                      Monkey Machine Ltd.
>   PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] Fw: [springframework - Help] Building Spring from source

[<tri...@tr...>]

I think this could be solved by having two separate downloads:

1. A distribution file for those using spring during application development.
This is what we ship today. I would also include the source for all tests - good
reference for how to use the framework.

2. A distribution file for those that want to explore Spring further, like build
and modify it.  These users today get it from CVS, but a zip file based on a
specific release would be good.  That would also make people more confident in
using a M4/RC1 in a production project.  You are ready to fix and rebuild the
framework.

Thomas

Quoting Rod Johnson <rod...@in...>:

> We definitely need the build script and properties in the release too, even
> if we don't ship all the binaries.
> 
> ----- Original Message ----- 
> From: "SourceForge.net" <no...@so...>
> To: <no...@so...>
> Sent: Friday, December 12, 2003 6:16 PM
> Subject: [springframework - Help] Building Spring from source
> 
> 
> >
> > Read and respond to this message at:
> > https://sourceforge.net/forum/message.php?msg_id=2330956
> > By: whitneyh
> >
> > Hello,
> >
> > Can you tell me what I need to build Spring from the source code? It does
> not
> > appear that an ant build file is included in the distribution and it does
> not
> > seem that all dependencies are resolved by the jars in the lib directory.
> >
> > Thank you,
> > Whitney Hunter
> >
> > ______________________________________________________________________
> > You are receiving this email because you elected to monitor this forum.
> > To stop monitoring this forum, login to SourceForge.net and visit:
> > https://sourceforge.net/forum/unmonitor.php?forum_id=250340
> >
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] Cannot passivate stateful session bean (again!)

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

I've made the logger non-final so that stateful session bean subclasses 
can remove and restore it in ejbPassivate/ejbActivate, respectively.

I considered nulling out the BeanFactoryLoader automatically on the 
unload call. On the other hand, I don't think this is always appropriate 
since some people don't use the default loader. I use my own loader for 
example, which is serializable, so there is no need to reset it each 
time (although I'm not using stateful beans anyways).


Alastair Rodgers wrote:

>Hi, 
>
>I've only just subscribed to the dev list, but someone told me there was a discussion earlier this week about failure to passivate stateful session beans. This was caused by the bean factory reference not being set to null on passivation. 
>
>I've come across a related problem, which seems to be due to the logger field in AbstractEnterpriseBean - I can't set its reference to null in ejbPassivate() because its final, so when my bean tries to passivate I get an exception saying that org.apache.commons.logging.impl.Log4JCategoryLog is not serializable (stacktrace below).
>
>Also, I've just taken a look at AbstractEnterpriseBean in CVS and it seems that unloadBeanFactory() only sets the ref to beanFactory to null, whereas the beanFactoryLoader ref remains set. I know I could just call setBeanFactoryLoader() in ejbPassivate() to set it to null, but wouldn't it be clearer to just have a single unload() method which unloads both references?
>
>Anyway, that aside, Spring is fantastic! Thanks.
>
>Al.
>
>
>
>javax.ejb.EJBException: Could not passivate; failed to save state; CausedByException is:
>	org.apache.commons.logging.impl.Log4JCategoryLog
>	at org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.passivateSession(StatefulSessionFilePersistenceManager.java:378)
>	at org.jboss.ejb.plugins.StatefulSessionInstanceCache.passivate(StatefulSessionInstanceCache.java:85)
>	at org.jboss.ejb.plugins.AbstractInstanceCache.tryToPassivate(AbstractInstanceCache.java:156)
>	at org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy$OveragerTask.run(LRUEnterpriseContextCachePolicy.java:435)
>	at java.util.TimerThread.mainLoop(Timer.java:432)
>	at java.util.TimerThread.run(Timer.java:382)
>java.io.NotSerializableException: org.apache.commons.logging.impl.Log4JCategoryLog
>	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
>	at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
>	at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
>	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
>	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
>	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
>	at org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.passivateSession(StatefulSessionFilePersistenceManager.java:370)
>	at org.jboss.ejb.plugins.StatefulSessionInstanceCache.passivate(StatefulSessionInstanceCache.java:85)
>	at org.jboss.ejb.plugins.AbstractInstanceCache.tryToPassivate(AbstractInstanceCache.java:156)
>	at org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy$OveragerTask.run(LRUEnterpriseContextCachePolicy.java:435)
>	at java.util.TimerThread.mainLoop(Timer.java:432)
>	at java.util.TimerThread.run(Timer.java:382)
>N?HY޵隊X???'???u?????S??+??l?(??{^?ا,?T^???l???z|???$?YlJ('??謀L?Z?x????j[y??z???b??kay????^?[h?+vh?
>X??z0??i????&?bt
>?ƥ??"t
>?Z)
?rD??)?~??{
>+?ׯzZ)z???X??X??*k?x???Š?u?ޖ?^?X???(??~??zw???i????l???q???z???l?X??)ߣ?)?)?~??{
>+?ׯzZ)er==
>