You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(55) |
Mar
(100) |
Apr
(203) |
May
(330) |
Jun
(190) |
Jul
(302) |
Aug
(323) |
Sep
(197) |
Oct
(245) |
Nov
(490) |
Dec
(330) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(194) |
Feb
(400) |
Mar
(416) |
Apr
(415) |
May
(359) |
Jun
(381) |
Jul
(491) |
Aug
(311) |
Sep
(291) |
Oct
(273) |
Nov
(355) |
Dec
(266) |
| 2005 |
Jan
(306) |
Feb
(303) |
Mar
(520) |
Apr
(346) |
May
(255) |
Jun
(221) |
Jul
(171) |
Aug
(247) |
Sep
(147) |
Oct
(125) |
Nov
(165) |
Dec
(65) |
| 2006 |
Jan
(90) |
Feb
(53) |
Mar
(121) |
Apr
(103) |
May
(113) |
Jun
(103) |
Jul
(104) |
Aug
(67) |
Sep
(78) |
Oct
(82) |
Nov
(78) |
Dec
(70) |
| 2007 |
Jan
(77) |
Feb
(76) |
Mar
(63) |
Apr
(30) |
May
(47) |
Jun
(41) |
Jul
(44) |
Aug
(44) |
Sep
(49) |
Oct
(33) |
Nov
(25) |
Dec
(21) |
| 2008 |
Jan
(45) |
Feb
(13) |
Mar
(15) |
Apr
(12) |
May
(9) |
Jun
(33) |
Jul
(30) |
Aug
(7) |
Sep
(20) |
Oct
(17) |
Nov
(20) |
Dec
(10) |
| 2009 |
Jan
(8) |
Feb
(5) |
Mar
(12) |
Apr
(17) |
May
(19) |
Jun
(97) |
Jul
(77) |
Aug
(33) |
Sep
(24) |
Oct
(41) |
Nov
(16) |
Dec
(32) |
| 2010 |
Jan
(24) |
Feb
(14) |
Mar
(50) |
Apr
(71) |
May
(70) |
Jun
(64) |
Jul
(45) |
Aug
(62) |
Sep
(32) |
Oct
(4) |
Nov
(12) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
(6) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(4) |
Feb
(8) |
Mar
(6) |
Apr
(10) |
May
(2) |
Jun
(3) |
Jul
(11) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(4) |
Feb
(1) |
Mar
(9) |
Apr
(1) |
May
(8) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(10) |
Dec
(8) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(12) |
May
(2) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(9) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(7) |
Oct
(9) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(7) |
Feb
(5) |
Mar
(5) |
Apr
(5) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(4) |
Sep
(6) |
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2017 |
Jan
(7) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <jue...@we...> - 2004-09-20 17:07:08
|
I agree: It would be great to get both into 1.1.1, which effectively = means getting them done within the next 10 days... =20 Juergen =20 ________________________________ From: spr...@li... on behalf of = Mark Pollack Sent: Mon 20/09/2004 18:18 To: spr...@li... Subject: RE: [Springframework-developer] Tests for receive on JMS 1.0.2 Hi, OK. Also there was a request to include support for printing the nested = JMS exception via the API call, JMSExcetpion.getLinkedException(). This = should also go in 1.1.1 I'd say. - Mark > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] > On Behalf Of j=FCrgen h=F6ller [werk3AT] > Sent: Saturday, September 18, 2004 3:21 PM > To: spr...@li... > Subject: [Springframework-developer] Tests for receive on JMS 1.0.2 > > > Mark, >=20 > On the occasion of refining our "acknowledge" calls on > received messages, I've noticed that we don't have tests for > receive functionality on JMS 1.0.2 yet. Do you have the > chance to add those, along the lines of the corresponding > tests in JmsTemplateTests? It would be great to complete > those for 1.1.1 (due by end of September). >=20 > Juergen > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one > of 170 Project Admins to receive an Apple iPod Mini FREE for > your judgement on who ports your project to Linux PPC the > best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: bryan <nih...@gm...> - 2004-09-20 16:32:05
|
If you use a non xml based import facility i think it will be harder to use
xml editors like xmlbuddy with them as there will be problems with entities
referencing entities that are not in the document, this will make it harder to
validate at development time.
Why not instead take the approach of a single big file like a registry
depending on a single properties file or set of preferences ( registry )
values.
The problem is that with some things like
org.springframework.web.context.ContextLoaderListener get the list of
properties files using a context-param.
How can the user change this unless she unzips the application, manually
edits the value and then redeploys it ?
Wouldn't it be far simpler from an end user ( at the end of the day they
drive requirements ) point of view if they could just run a simple program
which would edit the registry keys and then restart the application with the
changes happening automatically ?
Very few web applications are well designed from an installation/administration
point of view, but there are a couple that really stand such as the php based
squirrelmail.
It offers an easy to use perl config program that chooses sensible defaults for
the administrator but allows them to change them as they see fit.
If there is no chance of making the changes to the xml format perhaps it
would be good to at least allow some mechanism for changing the files that
ContextLoaderListener uses at runtime without unzip, edit xml, re-zip
cycle.
Not everyone is a programmer or technically literate, this is fine for some
but not fine for your average point and click windows "administrator".
--b
On Mon, 20 Sep 2004 08:15:41 -0400, Chris Eldredge
<chr...@co...> wrote:
> As my message stated, I think the import tag is a good feature and look
> forward to using it. It should solve your 3 * 300 problem.
>
> The part I take issue with is putting conditionals and other
> meta-programming into an xml file. Keep in mind, xml and IoC are
> intended to divorce configuration from the program. Turning a bean
> configuration file into a bean "script" entirely defeats that purpose
> because essentially you are putting the program into the configuration.
>
> What is the perceived advantage of using
>
> <condition test="foo"> <import name="sometimes.xml"> </condition>
>
> instead of the java equivalent:
>
> if (foo) {
> context = new ClassPathXmlApplicationContext(new String[] {"main.xml",
> "sometimes.xml"});
> } else {
> context = new ClassPathXmlApplicationContext(new String[] {"main.xml"});
> }
>
> All you would be doing is mixing your configuration with your program.
>
>
>
> bryan wrote:
> > Chris,
> >
> > You must really like keeping 3 * 300 line files in sync with each
> > other when just
> > 60/70 lines are different in each one .....
> >
> > I'm not talking about adding #ifdef and #define to the top of your java source
> > files here !
> >
> > --b
> >
> >
> >
> > On Thu, 16 Sep 2004 14:46:45 -0400, Chris Eldredge
> > <chr...@co...> wrote:
> >
> >>bryan wrote:
> >>
> >>
> >>><beans>
> >>><if value="test" equals="test">
> >>> <import resource="myImport1.xml"/>
> >>></if>
> >>
> >>This looks an awful lot like meta-programming to me. This becomes a
> >>slippery slope. IMO, xml bean files should be for configuration, not
> >>for scripting.
> >>
> >>The <import>, however, is something that I am looking forward to using
> >>on my current project.
> >>
> >>Chris.
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> >>Project Admins to receive an Apple iPod Mini FREE for your judgement on
> >>who ports your project to Linux PPC the best. Sponsored by IBM.
> >>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> >>_______________________________________________
> >>Springframework-developer mailing list
> >>Spr...@li...
> >>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> > Project Admins to receive an Apple iPod Mini FREE for your judgement on
> > who ports your project to Linux PPC the best. Sponsored by IBM.
> > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|
|
From: Mark P. <mar...@co...> - 2004-09-20 16:18:17
|
Hi, OK. Also there was a request to include support for printing the nested = JMS exception via the API call, JMSExcetpion.getLinkedException(). This = should also go in 1.1.1 I'd say. - Mark > -----Original Message----- > From: spr...@li...=20 > [mailto:spr...@li...] > On Behalf Of j=FCrgen h=F6ller [werk3AT] > Sent: Saturday, September 18, 2004 3:21 PM > To: spr...@li... > Subject: [Springframework-developer] Tests for receive on JMS 1.0.2 >=20 >=20 > Mark, > =20 > On the occasion of refining our "acknowledge" calls on=20 > received messages, I've noticed that we don't have tests for=20 > receive functionality on JMS 1.0.2 yet. Do you have the=20 > chance to add those, along the lines of the corresponding=20 > tests in JmsTemplateTests? It would be great to complete=20 > those for 1.1.1 (due by end of September). > =20 > Juergen >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one=20 > of 170 Project Admins to receive an Apple iPod Mini FREE for=20 > your judgement on who ports your project to Linux PPC the=20 > best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php=20 > _______________________________________________ > Springframework-developer mailing list=20 > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 |
|
From: Chris E. <chr...@co...> - 2004-09-20 12:14:13
|
As my message stated, I think the import tag is a good feature and look
forward to using it. It should solve your 3 * 300 problem.
The part I take issue with is putting conditionals and other
meta-programming into an xml file. Keep in mind, xml and IoC are
intended to divorce configuration from the program. Turning a bean
configuration file into a bean "script" entirely defeats that purpose
because essentially you are putting the program into the configuration.
What is the perceived advantage of using
<condition test="foo"> <import name="sometimes.xml"> </condition>
instead of the java equivalent:
if (foo) {
context = new ClassPathXmlApplicationContext(new String[] {"main.xml",
"sometimes.xml"});
} else {
context = new ClassPathXmlApplicationContext(new String[] {"main.xml"});
}
All you would be doing is mixing your configuration with your program.
bryan wrote:
> Chris,
>
> You must really like keeping 3 * 300 line files in sync with each
> other when just
> 60/70 lines are different in each one .....
>
> I'm not talking about adding #ifdef and #define to the top of your java source
> files here !
>
> --b
>
>
>
> On Thu, 16 Sep 2004 14:46:45 -0400, Chris Eldredge
> <chr...@co...> wrote:
>
>>bryan wrote:
>>
>>
>>><beans>
>>><if value="test" equals="test">
>>> <import resource="myImport1.xml"/>
>>></if>
>>
>>This looks an awful lot like meta-programming to me. This becomes a
>>slippery slope. IMO, xml bean files should be for configuration, not
>>for scripting.
>>
>>The <import>, however, is something that I am looking forward to using
>>on my current project.
>>
>>Chris.
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>>who ports your project to Linux PPC the best. Sponsored by IBM.
>>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
|
|
From: <jue...@we...> - 2004-09-20 08:39:20
|
Or rework it to use a Commons Logging log category rather than the = console... calling it "EventLoggingListener" or the like? Then it would = still be appropriate for our main source tree, I guess.. =20 Juergen =20 ________________________________ From: spr...@li... on behalf of = Rod Johnson Sent: Sun 19/09/2004 17:03 To: spr...@li... Subject: RE: [Springframework-developer] ConsoleListener I think in this case we could actually *remove* it--or perhaps, move it = to the mock tree. It has some value for prototyping perhaps. -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of j=FCrgen h=F6ller [werk3AT] Sent: 18 September 2004 23:44 To: spr...@li... Subject: Re: [Springframework-developer] ConsoleListener I agree - there's not much point in keeping it. Let's deprecate it for 1.1.1! Juergen ________________________________ Von: spr...@li... im Auftrag = von Dmitriy Kopylenko Gesendet: Sa 18.09.2004 23:29 An: spr...@li... Betreff: [Springframework-developer] ConsoleListener I'm just wondering - does anyone use org.springframework.context.event.ConsoleListener? If not really, can we "retire" it? Dmitriy. ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 = Project Admins to receive an Apple iPod Mini FREE for your judgement on who = ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 = Project Admins to receive an Apple iPod Mini FREE for your judgement on who = ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Dmitriy K. <dko...@ru...> - 2004-09-19 15:31:05
|
I've added "org.springframework.cache.ehcache.EhCacheManagerFactoryBean" and "org.springframework.cache.ehcache.EhCacheFactoryBean" to the sandbox. Please take a look at it with any suggestions and/or comments. Now, if we would provide such caching support classes, where would they live. Is "org.springframework.cache" top level package appropriate with sub packages for different caching subsystems i.e "ehcache", "oscache", etc.? If we all agree on the package for caching support classes, EHCache factory beans might make 1.1.1 Regards, Dmitriy. |
|
From: Rod J. <ro...@in...> - 2004-09-19 15:04:20
|
I think in this case we could actually *remove* it--or perhaps, move it = to the mock tree. It has some value for prototyping perhaps. -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of j=FCrgen h=F6ller [werk3AT] Sent: 18 September 2004 23:44 To: spr...@li... Subject: Re: [Springframework-developer] ConsoleListener I agree - there's not much point in keeping it. Let's deprecate it for 1.1.1! =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Dmitriy Kopylenko Gesendet: Sa 18.09.2004 23:29 An: spr...@li... Betreff: [Springframework-developer] ConsoleListener I'm just wondering - does anyone use org.springframework.context.event.ConsoleListener? If not really, can we "retire" it? Dmitriy. ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 = Project Admins to receive an Apple iPod Mini FREE for your judgement on who = ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 = Project Admins to receive an Apple iPod Mini FREE for your judgement on who = ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-09-18 22:44:32
|
I agree - there's not much point in keeping it. Let's deprecate it for = 1.1.1! =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Dmitriy Kopylenko Gesendet: Sa 18.09.2004 23:29 An: spr...@li... Betreff: [Springframework-developer] ConsoleListener I'm just wondering - does anyone use org.springframework.context.event.ConsoleListener? If not really, can we "retire" it? Dmitriy. ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Dmitriy K. <dko...@ru...> - 2004-09-18 20:32:35
|
I'm just wondering - does anyone use org.springframework.context.event.ConsoleListener? If not really, can we "retire" it? Dmitriy. |
|
From: <jue...@we...> - 2004-09-18 19:20:50
|
Mark, =20 On the occasion of refining our "acknowledge" calls on received = messages, I've noticed that we don't have tests for receive = functionality on JMS 1.0.2 yet. Do you have the chance to add those, = along the lines of the corresponding tests in JmsTemplateTests? It would = be great to complete those for 1.1.1 (due by end of September). =20 Juergen |
|
From: Olivier J. <oli...@pc...> - 2004-09-18 15:19:51
|
Hi, in reply to my ldap contribution proposition, here is an archive with the source code for it (I'm not sure if a diff would have been useful, as it is only new files). Sorry for the delay but I've been sick recently and couldn't make it as fast as I expected. As stated in earlier mails, there is no support for transactions at all. I tried to mimic as much as possible the jdbc implementation, in the names, javadoc and such. Obviously, there are some large differences, besides transactions. Operations in ldap aren't as homogeneous as with SQL. On a DirContext, you have different access point for creation, deletion, retrieving, ... I have provided a generic entry point in the LdapTemplate.execute which is parameterized by callback, where you implement a method which is given a DirContext which is automatically freed. The DirContext instance is taken from an implementation of ContextSource, which is similar to the DataSource in the JDBC world. It allows the LdapTemplate to be reusable as, a new DirContext is retrieved at each call. This DirContext is not only a connection to a server, but also a location inside the directory, it is thus interesting as it allows to bind a LdapTemplate to a given object via IoC (the UrlContextSource and RelativeContextSource been classical implementation parametrized by spring container). Next to the execute method, there is a couple of searching methods wrapper which takes a SearchResultCallbackHandler besides the usual arguments. This callback is then executed on each hit and a getResult method on the callback is used to make it the result of the search method. I find it interesting in terms of reduction of code needed to make most usual operations. Of course, exceptions are (normally) translated from the LDAP specific world into the generic dao ones (as soon as I'll have the class written, there is a placeholder for now). Since there are already categorized, I'm not even sure I need to offer a choice of translater as needed for JDBC. I also did a AttributeHelper class to work more easily with attribute retrieving. Nothing fancy there. I would like to know whether it is interesting enough to integrate the cvs and if the design suits you. I'm far from being the java experts who lurk on this list. I'm open to any suggestions to improve it. Best regards all Olivier |
|
From: Dmitriy K. <dko...@ru...> - 2004-09-18 14:14:13
|
Juergen, The main reason I've introduced ApplicationEventPublisher interface is to factor out event publishing from the ApplicationContext interface. I am totally happy with your suggested design. Regards, Dmitriy. jürgen höller [werk3AT] wrote: >Dmitriy, > >I've seen that you've added an ApplicationEventPublisher interface plus SimpleApplicationEventPublisher implementation, used as base class for EventPublicationInterceptor. I'm not sure if those really add value: EventPublicationInterceptor *derives* from SimpleApplicationEventPublisher, so it doesn't leverage the pluggability offered by the ApplicationEventPublisher interface. > >If we want to factor out event publishing from the ApplicationContext interface, I suggest to add an ApplicationEventPublisher interface to the org.springframework.context package, extended by the ApplicationContext interface. We've used the same strategy for the MessageSource and ResourceLoader interfaces. (Have a look at the interfaces that ApplicationContext extends.) > >We could then add an ApplicationEventPublisherAware interface, which beans can implement to automatically receive a reference to an ApplicationEventPublisher (usually the containing ApplicationContext). EventPublicationInterceptor can then simply implement that interface, rather than ApplicationContextAware, allowing it to be used with any ApplicationEventPublisher. > >For a comparison, have a look at the ReloadableResourceBundleMessageSource's implementation: It implements ResourceLoaderAware to automatically receive a containing ApplicationContext as ResourceLoader. Additionally, it has a DefaultResourceLoader as default, to allow for usage outside an ApplicationContext too. You could also pass in a custom ResourceLoader implementation. > >What do you think? If my suggested redesign fits your needs, I'm happy to apply it before the 1.1.1 release. > >Juergen > > > >------------------------------------------------------- >This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >Project Admins to receive an Apple iPod Mini FREE for your judgement on >who ports your project to Linux PPC the best. Sponsored by IBM. >Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: <jue...@we...> - 2004-09-18 10:00:19
|
Dmitriy, =20 I've seen that you've added an ApplicationEventPublisher interface plus = SimpleApplicationEventPublisher implementation, used as base class for = EventPublicationInterceptor. I'm not sure if those really add value: = EventPublicationInterceptor *derives* from = SimpleApplicationEventPublisher, so it doesn't leverage the pluggability = offered by the ApplicationEventPublisher interface. =20 If we want to factor out event publishing from the ApplicationContext = interface, I suggest to add an ApplicationEventPublisher interface to = the org.springframework.context package, extended by the = ApplicationContext interface. We've used the same strategy for the = MessageSource and ResourceLoader interfaces. (Have a look at the = interfaces that ApplicationContext extends.) =20 We could then add an ApplicationEventPublisherAware interface, which = beans can implement to automatically receive a reference to an = ApplicationEventPublisher (usually the containing ApplicationContext). = EventPublicationInterceptor can then simply implement that interface, = rather than ApplicationContextAware, allowing it to be used with any = ApplicationEventPublisher. =20 For a comparison, have a look at the = ReloadableResourceBundleMessageSource's implementation: It implements = ResourceLoaderAware to automatically receive a containing = ApplicationContext as ResourceLoader. Additionally, it has a = DefaultResourceLoader as default, to allow for usage outside an = ApplicationContext too. You could also pass in a custom ResourceLoader = implementation. =20 What do you think? If my suggested redesign fits your needs, I'm happy = to apply it before the 1.1.1 release. =20 Juergen =20 |
|
From: Dmitriy K. <dko...@ru...> - 2004-09-17 21:20:51
|
I would love to take a look at that... Dmitriy. Rob Harrop wrote: > I have the basics of Jasper Reports support done for the MVC view. I > haven't yet looked in much detail at a helper library for the ui > package but I have identified some methods that need to be in there. > > If everyone is happy I will add jasperreports JAR to CVS and commit > what I have in sandbox for everyone to try out. Not much in the way of > unit tests yet, but I have a small sample application running locally > that generates reports in PDF, HTML, Excel and CSV - which is nice. > > Rob > > jürgen höller [werk3AT] wrote: > >>> Is there any possibility of creating a layer that would be common to >>> both web and rich client UIs? In other words, as much as is common >>> between the two approaches goes into a separate layer for maximum >>> reuse. >>> >> >> >> Effectively, we've already started this through our >> "org.springframework.ui" package, which currently contains theme >> support and generic template support for Velocity/FreeMarker. The web >> package builds on those for web-specific themes and >> Velocity/FreeMarker views. Similar support classes like for Jasper >> reports could go into the "ui" package too, I guess. >> >> Juergen >> >> >> -----Original Message----- >> From: spr...@li... >> [mailto:spr...@li...]On Behalf >> Of Andy Depue >> Sent: Thursday, September 16, 2004 11:33 PM >> To: spr...@li... >> Subject: Re: [Springframework-developer] Jasper Reports Support >> >> >> This is interesting. We are currently developing a rich (internet) >> client using spring-rich and will have need to not only display >> Jasper reports but also to link the reports to our app for drill down >> purposes (in other words, placing hyperlinks in the report that our >> app can intercept and respond to). Is there any possibility of >> creating a layer that would be common to both web and rich client >> UIs? In other words, as much as is common between the two approaches >> goes into a separate layer for maximum reuse. >> >> - Andy >> >> On Thursday 16 September 2004 01:06 pm, Rob Harrop wrote: >> >> >>> All, >>> >>> I am looking at adding view support for Jasper Reports to Spring MVC >>> and >>> want to get some input before I dive in. >>> >>> My first question is what approach would everyone prefer. >>> >>> I could go for a document style approach like PDF and Excel providing >>> hooks for you to expose properties and a JRDatasource, or I could >>> create >>> a subclass of AbstractUrlBasedView and then auto expose all properties >>> in the model to Jasper Reports, grabbing the datasource from there by >>> type. My preference is for the second approach since it requires less >>> coding from the end user. >>> >>> What does everyone think? >>> >>> Rob >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >>> Project Admins to receive an Apple iPod Mini FREE for your judgement on >>> who ports your project to Linux PPC the best. Sponsored by IBM. >>> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php >>> _______________________________________________ >>> Springframework-developer mailing list >>> Spr...@li... >>> https://lists.sourceforge.net/lists/listinfo/springframework-developer >>> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >> Project Admins to receive an Apple iPod Mini FREE for your judgement on >> who ports your project to Linux PPC the best. Sponsored by IBM. >> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >> Project Admins to receive an Apple iPod Mini FREE for your judgement on >> who ports your project to Linux PPC the best. Sponsored by IBM. >> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >> > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Rob H. <ro...@ca...> - 2004-09-17 20:53:54
|
I have the basics of Jasper Reports support done for the MVC view. I haven't yet looked in much detail at a helper library for the ui package but I have identified some methods that need to be in there. If everyone is happy I will add jasperreports JAR to CVS and commit what I have in sandbox for everyone to try out. Not much in the way of unit tests yet, but I have a small sample application running locally that generates reports in PDF, HTML, Excel and CSV - which is nice. Rob jürgen höller [werk3AT] wrote: >>Is there any possibility of creating a layer that would be common to both web >>and rich client UIs? In other words, as much as is common between the two >>approaches goes into a separate layer for maximum reuse. >> >> > >Effectively, we've already started this through our "org.springframework.ui" package, which currently contains theme support and generic template support for Velocity/FreeMarker. The web package builds on those for web-specific themes and Velocity/FreeMarker views. Similar support classes like for Jasper reports could go into the "ui" package too, I guess. > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of Andy Depue >Sent: Thursday, September 16, 2004 11:33 PM >To: spr...@li... >Subject: Re: [Springframework-developer] Jasper Reports Support > > >This is interesting. We are currently developing a rich (internet) client >using spring-rich and will have need to not only display Jasper reports but >also to link the reports to our app for drill down purposes (in other words, >placing hyperlinks in the report that our app can intercept and respond to). >Is there any possibility of creating a layer that would be common to both web >and rich client UIs? In other words, as much as is common between the two >approaches goes into a separate layer for maximum reuse. > > - Andy > >On Thursday 16 September 2004 01:06 pm, Rob Harrop wrote: > > >>All, >> >>I am looking at adding view support for Jasper Reports to Spring MVC and >>want to get some input before I dive in. >> >>My first question is what approach would everyone prefer. >> >>I could go for a document style approach like PDF and Excel providing >>hooks for you to expose properties and a JRDatasource, or I could create >>a subclass of AbstractUrlBasedView and then auto expose all properties >>in the model to Jasper Reports, grabbing the datasource from there by >>type. My preference is for the second approach since it requires less >>coding from the end user. >> >>What does everyone think? >> >>Rob >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >>Project Admins to receive an Apple iPod Mini FREE for your judgement on >>who ports your project to Linux PPC the best. Sponsored by IBM. >>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >>https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> > > >------------------------------------------------------- >This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >Project Admins to receive an Apple iPod Mini FREE for your judgement on >who ports your project to Linux PPC the best. Sponsored by IBM. >Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > >------------------------------------------------------- >This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >Project Admins to receive an Apple iPod Mini FREE for your judgement on >who ports your project to Linux PPC the best. Sponsored by IBM. >Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > |
|
From: bryan <nih...@gm...> - 2004-09-17 13:15:54
|
It is true, i tried implementing this myself and had no success. It is caused by the fact that "Bean definitions in ancestor contexts are visible to descendant contexts but never the reverse" ... is there a specific reaso= n=20 for this apart from preventing endless loops etc ?=20 --b On Fri, 17 Sep 2004 14:57:47 +0200, j=FCrgen h=F6ller [ werk3AT ] <jue...@we...> wrote: > I can certainly add support for a delimited list of resource locations. H= owever, you will not be able to use a PropertyPlaceholderConfigurer for tho= se locations: Such BeanFactoryPostProcessors get applied after all bean def= initions have been registered. And I don't see a chance to change this with= the current semantics... >=20 > Juergen >=20 >=20 > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...]On Behalf > Of bryan > Sent: Thursday, September 16, 2004 6:04 PM > To: spr...@li... > Subject: Re: [Springframework-developer] Import tag for XML bean > definitions >=20 > juergen .... you are a legend !!!! >=20 > Hey one thing though .. >=20 > Would it be possible to allow the user to specify a list like > so ....... >=20 > <import resource=3D"myImport1.xml,myImport2.xml,myImport3.xml"/> >=20 > The reason that this would be *super* *super* usefull is because then > users could store these values in a properties file or in the registry > using the Preferences API and then use the property placeholder > configurer to fill in the blanks at runtime. >=20 > On other thing ..... if you wanted to be super smart and really show off > heres a cool feature .... >=20 > <beans> > <if value=3D"test" equals=3D"test"> > <import resource=3D"myImport1.xml"/> > </if> >=20 > <bean ... /> >=20 > </beans> >=20 > --b >=20 > On Thu, 16 Sep 2004 10:22:12 +0200, j=FCrgen h=F6ller [ werk3AT ] >=20 >=20 > <jue...@we...> wrote: > > Hi everybody, > > > > During an extra evening I had to spend at an airport hotel in Rome, I'v= e implemented an "import" tag for XML bean definitions: > > > > http://opensource.atlassian.com/projects/spring/browse/SPR-137 > > > > Basically, you can put any number of "import" tags at the beginning of = bean definition files: > > > > <beans> > > > > <import resource=3D"myImport1.xml"/> > > <import resource=3D"myImport2.xml"/> > > > > <bean ... /> > > > > </beans> > > > > The resource locations are interpreted as relative to the file that con= tains the import tags. Effectively, this is delegated to the "createRelativ= e" method on the Resource interface, invoked on the Resource object for the= containing file. ("createRelative" has already been introduced in 1.1 fina= l.) > > > > I'll commit this tonight, provided that there aren't any objections. Wh= ile I'm not gonna recommend this feature too much, as I personally prefer a= "contextConfigLocation" that refers to multiple files, I still believe tha= t an import tag is a useful addition. In particular, some people are used t= o such a feature from Ant and XWork... > > > > Juergen > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > Project Admins to receive an Apple iPod Mini FREE for your judgement on > > who ports your project to Linux PPC the best. Sponsored by IBM. > > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: <jue...@we...> - 2004-09-17 13:02:49
|
I personally prefer to specify multiple bean definitions files via a =
"contextConfigLocation" that contains multiple resource paths. This =
allows to drive combinations through that init-param, without having to =
touch the bean definition files themselves: for example, to easily =
switch between "dataAccessContext-hibernate.xml" and =
"dataAccessContext-jdbc.xml".
I guess it boils down to a matter of taste: Both ways have their =
individual merits. That's why I finally added the "import" tag (which is =
still not committed, BTW - will do so tonight).
If a single file gets loaded multiple times for a single context, later =
bean definitions will simply replace existing ones of the same name. =
There is no explicit check for duplicate files: This rather works at the =
individual bean definition level.
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Keith
Sent: Thursday, September 16, 2004 4:34 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Import tag for XML bean
definitions
This sounds great! Just curious, why wouldn't you recommend it too =
much? =20
I know I've had mention before people wanting to see logically how the =
files
are related - when they're looking at the files (rather than going to
bootstrap configuration, generally separate.) Kind of a "less magic" =
thing.
I think the import tag, like the recent abstract attribute for abstract =
bean
definitions, can help make things more explicit.
<beans description=3D"Business layer services definitions">
<import resource=3D"data-access.xml"
description=3D"Import dependent DAO definitions"/>
<bean> ... </bean>
...
</beans>
Just curious: if I was to do like above, and still bootstrap a single
application context with "business-layer.xml" and "data-access.xml" as
opposed to just "business-layer" - what happens?
Let's say I had a "utilities-context.xml" with utility beans used by my
other contexts (like PropertyPlaceholderConfigurer), used by business =
and
dao. If I imported that guy into those files, but in the end everything
resulted in a flat "big" context -- what would happen?
Getting code churned out at the airport is the best! :-) Keith=20
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: Thursday, September 16, 2004 4:22 AM
To: spr...@li...
Subject: [Springframework-developer] Import tag for XML bean definitions
Hi everybody,
During an extra evening I had to spend at an airport hotel in Rome, I've
implemented an "import" tag for XML bean definitions:
http://opensource.atlassian.com/projects/spring/browse/SPR-137
Basically, you can put any number of "import" tags at the beginning of =
bean
definition files:
<beans>
<import resource=3D"myImport1.xml"/>
<import resource=3D"myImport2.xml"/>
<bean ... />
</beans>
The resource locations are interpreted as relative to the file that =
contains
the import tags. Effectively, this is delegated to the "createRelative"
method on the Resource interface, invoked on the Resource object for the
containing file. ("createRelative" has already been introduced in 1.1
final.)
I'll commit this tonight, provided that there aren't any objections. =
While
I'm not gonna recommend this feature too much, as I personally prefer a
"contextConfigLocation" that refers to multiple files, I still believe =
that
an import tag is a useful addition. In particular, some people are used =
to
such a feature from Ant and XWork...
Juergen
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <jue...@we...> - 2004-09-17 12:57:32
|
I can certainly add support for a delimited list of resource locations. = However, you will not be able to use a PropertyPlaceholderConfigurer for = those locations: Such BeanFactoryPostProcessors get applied after all = bean definitions have been registered. And I don't see a chance to = change this with the current semantics... Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of bryan Sent: Thursday, September 16, 2004 6:04 PM To: spr...@li... Subject: Re: [Springframework-developer] Import tag for XML bean definitions juergen .... you are a legend !!!!=20 Hey one thing though .. Would it be possible to allow the user to specify a list like=20 so .......=20 <import resource=3D"myImport1.xml,myImport2.xml,myImport3.xml"/> The reason that this would be *super* *super* usefull is because then=20 users could store these values in a properties file or in the registry using the Preferences API and then use the property placeholder=20 configurer to fill in the blanks at runtime.=20 On other thing ..... if you wanted to be super smart and really show off = heres a cool feature ....=20 <beans> <if value=3D"test" equals=3D"test"> <import resource=3D"myImport1.xml"/> </if> <bean ... /> </beans> --b On Thu, 16 Sep 2004 10:22:12 +0200, j=FCrgen h=F6ller [ werk3AT ] <jue...@we...> wrote: > Hi everybody, >=20 > During an extra evening I had to spend at an airport hotel in Rome, = I've implemented an "import" tag for XML bean definitions: >=20 > http://opensource.atlassian.com/projects/spring/browse/SPR-137 >=20 > Basically, you can put any number of "import" tags at the beginning of = bean definition files: >=20 > <beans> >=20 > <import resource=3D"myImport1.xml"/> > <import resource=3D"myImport2.xml"/> >=20 > <bean ... /> >=20 > </beans> >=20 > The resource locations are interpreted as relative to the file that = contains the import tags. Effectively, this is delegated to the = "createRelative" method on the Resource interface, invoked on the = Resource object for the containing file. ("createRelative" has already = been introduced in 1.1 final.) >=20 > I'll commit this tonight, provided that there aren't any objections. = While I'm not gonna recommend this feature too much, as I personally = prefer a "contextConfigLocation" that refers to multiple files, I still = believe that an import tag is a useful addition. In particular, some = people are used to such a feature from Ant and XWork... >=20 > Juergen >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement = on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-09-17 12:55:13
|
I'm not sure whether such a "transform-with" attribute would just apply =
to the import tag: This should be available for all XML bean definition =
files, not just for imported ones. The question is, how to specify the =
XSL file for a "contextConfigLocation" in web.xml, for example, or for a =
FileSystemXmlApplicationContext?
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Andy Depue
Sent: Thursday, September 16, 2004 5:21 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Import tag for XML bean
definitions
I like having this option. One thought this triggered in my head is the =
possibility of having application oriented XML config files. In other =
words,=20
config files that are oriented around your app so that they become =
easier to=20
work with for the masses. ActiveMQ and Mule are two systems that allow =
you=20
to either configure via Spring or configure via a native XML that is=20
typically easier to work with. ActiveMQ actually uses XSL internally to =
translate from the ActiveMQ oriented XML config to a Spring config. So, =
having said all this, would it make sense to add an xsl (or =
transform-with)=20
attribute to the import tag? I could then do something like this:
<beans>
<import resource=3D"app-config.xml" =
transform-with=3D"app-to-spring.xsl"/>
...
</beans>
Thoughts?
- Andy
On Thursday 16 September 2004 01:22 am, j=FCrgen h=F6ller [werk3AT] =
wrote:
> Hi everybody,
>
> During an extra evening I had to spend at an airport hotel in Rome, =
I've
> implemented an "import" tag for XML bean definitions:
>
> http://opensource.atlassian.com/projects/spring/browse/SPR-137
>
> Basically, you can put any number of "import" tags at the beginning of =
bean
> definition files:
>
> <beans>
>
> <import resource=3D"myImport1.xml"/>
> <import resource=3D"myImport2.xml"/>
>
> <bean ... />
>
> </beans>
>
> The resource locations are interpreted as relative to the file that
> contains the import tags. Effectively, this is delegated to the
> "createRelative" method on the Resource interface, invoked on the =
Resource
> object for the containing file. ("createRelative" has already been
> introduced in 1.1 final.)
>
> I'll commit this tonight, provided that there aren't any objections. =
While
> I'm not gonna recommend this feature too much, as I personally prefer =
a
> "contextConfigLocation" that refers to multiple files, I still believe =
that
> an import tag is a useful addition. In particular, some people are =
used to
> such a feature from Ant and XWork...
>
> Juergen
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement =
on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <jue...@we...> - 2004-09-17 12:49:23
|
> Is there any possibility of creating a layer that would be common to = both web=20 > and rich client UIs? In other words, as much as is common between the = two=20 > approaches goes into a separate layer for maximum reuse. Effectively, we've already started this through our = "org.springframework.ui" package, which currently contains theme support = and generic template support for Velocity/FreeMarker. The web package = builds on those for web-specific themes and Velocity/FreeMarker views. = Similar support classes like for Jasper reports could go into the "ui" = package too, I guess. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Andy Depue Sent: Thursday, September 16, 2004 11:33 PM To: spr...@li... Subject: Re: [Springframework-developer] Jasper Reports Support This is interesting. We are currently developing a rich (internet) = client=20 using spring-rich and will have need to not only display Jasper reports = but=20 also to link the reports to our app for drill down purposes (in other = words,=20 placing hyperlinks in the report that our app can intercept and respond = to). =20 Is there any possibility of creating a layer that would be common to = both web=20 and rich client UIs? In other words, as much as is common between the = two=20 approaches goes into a separate layer for maximum reuse. - Andy On Thursday 16 September 2004 01:06 pm, Rob Harrop wrote: > All, > > I am looking at adding view support for Jasper Reports to Spring MVC = and > want to get some input before I dive in. > > My first question is what approach would everyone prefer. > > I could go for a document style approach like PDF and Excel providing > hooks for you to expose properties and a JRDatasource, or I could = create > a subclass of AbstractUrlBasedView and then auto expose all properties > in the model to Jasper Reports, grabbing the datasource from there by > type. My preference is for the second approach since it requires less > coding from the end user. > > What does everyone think? > > Rob > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement = on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-09-17 12:43:30
|
Darren,
Indeed, that's a bug. I've already discovered and fixed it during the =
"import" tag stuff I worked on (last week, in the airport hotel in =
Rome). I initially wanted to commit all of that yesterday, but =
unfortunately I didn't make it. Will commit everything tonight.
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Darren Davison
Sent: Friday, September 17, 2004 2:31 PM
To: spr...@li...
Subject: [Springframework-developer] bug in ClassPathResource?
createRelative(String) in ClassPathResource attempts to create a =
Resource
relative to only the FIRST part of the package name rather than all of =
it. So
if I have..
Resource root =3D new ClassPathResource("com/foo/bar/");
Resource res=3D root.createRelative("myFile.xml");
I would *expect* res.path to be "com/foo/bar/myFile.xml" instead it is
"com/myFile.xml"
Am I missing something? If not, I think the quickest fix is on line 117
(untested):
- int packageIndex =3D this.path.indexOf('/');
+ int packageIndex =3D this.path.lastIndexOf('/');
Regards,
--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Darren D. <da...@da...> - 2004-09-17 12:31:00
|
createRelative(String) in ClassPathResource attempts to create a Resource
relative to only the FIRST part of the package name rather than all of it=
. So
if I have..
Resource root =3D new ClassPathResource("com/foo/bar/");
Resource res=3D root.createRelative("myFile.xml");
I would *expect* res.path to be "com/foo/bar/myFile.xml" instead it is
"com/myFile.xml"
Am I missing something? If not, I think the quickest fix is on line 117
(untested):
- int packageIndex =3D this.path.indexOf('/');
+ int packageIndex =3D this.path.lastIndexOf('/');
Regards,
--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm
|
|
From: bryan <nih...@gm...> - 2004-09-17 12:22:28
|
If you were to do it that way would you still be able to use the properties/preferencesPlaceHolderConfigurer ? Do those properties need to be applied to a complete field ? Would it be possible to set those values at the top of the file like in ant where you can set properties ? How would you load the variables ? A custom PropertyAccessor ? --b On Thu, 16 Sep 2004 21:28:51 -0700, Drew Davidson <dr...@og...> wrote: > bryan wrote: > > >juergen .... you are a legend !!!! > > > >Hey one thing though .. > > > >Would it be possible to allow the user to specify a list like > >so ....... > > > > <import resource="myImport1.xml,myImport2.xml,myImport3.xml"/> > > > >The reason that this would be *super* *super* usefull is because then > >users could store these values in a properties file or in the registry > >using the Preferences API and then use the property placeholder > >configurer to fill in the blanks at runtime. > > > >On other thing ..... if you wanted to be super smart and really show off > >heres a cool feature .... > > > ><beans> > ><if value="test" equals="test"> > > <import resource="myImport1.xml"/> > ></if> > > > > <bean ... /> > > > > > ></beans> > > > > > > Better yet is for me to get myself in gear and start putting OGNL > support into Spring for 1.3. Then it would be: > > <beans> > <if condition="somevalue == 1"> > <import resource="myImport1.xml"/> > </if> > </beans> > > - Drew > > -- > +---------------------------------+ > < Drew Davidson | OGNL Technology > > +---------------------------------+ > | Email: dr...@og... / > | Web: http://www.ognl.org / > | Vox: (520) 531-1966 < > | Fax: (520) 531-1965 \ > | Mobile: (520) 405-2967 \ > +---------------------------------+ > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Alef A. <al...@jt...> - 2004-09-17 07:12:23
|
Paul, Have a look at the following question on the forum (which I think is the better place to post questions, they get answered much quicker than on the developers list). http://forum.springframework.org/viewtopic.php?t=3D756&highlight=3D Lukt het verder een beetje ;-)? Gr. Alef =20 > -----Original Message----- > From: spr...@li...=20 > [mailto:spr...@li...] > On Behalf Of 452 - Buying, Paul > Sent: Tuesday, September 14, 2004 3:46 PM > To: spr...@li... > Subject: [Springframework-developer] Error bean container on=20 > bean constructor argument >=20 >=20 > Dear list, >=20 > I've been working with an error on a constructor argument in=20 > the bean container. Spring seems to have problems with a=20 > primitive boolean <constructor-arg> in a <bean> as in: >=20 > <constructor-arg><value>true</value></constructor-arg> >=20 > But this is the way to go right? It says so in the Spring ref. >=20 > The error I get is this: >=20 > org.springframework.beans.factory.UnsatisfiedDependencyExcepti > on: Error creating bean with name 'customDateEditor' defined=20 > in resource [/WEB-INF/applicationContext.xml] of=20 > ServletContext: Unsatisfied dependency expressed through=20 > constructor argument with index 1 of type > [boolean]: Did you specify the correct bean references as=20 > generic constructor arguments? >=20 > The other arg is a SimpleDateFormat, here the whole definition. >=20 >=20 > <bean id=3D"customEditorConfigurer" > class=3D"org.springframework.beans.factory.config.CustomEditorCo > nfigurer"> > <property name=3D"customEditors"> > <map> > <entry key=3D"java.util.Date"><ref=20 > local=3D"customDateEditor"/></entry> > </map> > </property> > </bean> >=20 > <bean id=3D"customDateEditor" > class=3D"org.springframework.beans.propertyeditors.CustomDateEditor"> > <constructor-arg><ref > local=3D"dateFormatSql"/></constructor-arg> > <constructor-arg><value>true</value></constructor-arg> > </bean> >=20 > <bean id=3D"dateFormatSql" class=3D"java.text.SimpleDateFormat"> > =09 > <constructor-arg><value>yyyy-MM-dd</value></constructor-arg> > </bean> >=20 >=20 > The obvious goal here is simply to get a CustomDateEditor registered. >=20 > Thank ahead! >=20 > Paul. >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one=20 > of 170 Project Admins to receive an Apple iPod Mini FREE for=20 > your judgement on who ports your project to Linux PPC the=20 > best. Sponsored by IBM.=20 > Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php=20 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 >=20 >=20 |
|
From: Drew D. <dr...@og...> - 2004-09-17 04:29:18
|
bryan wrote:
>juergen .... you are a legend !!!!
>
>Hey one thing though ..
>
>Would it be possible to allow the user to specify a list like
>so .......
>
> <import resource="myImport1.xml,myImport2.xml,myImport3.xml"/>
>
>The reason that this would be *super* *super* usefull is because then
>users could store these values in a properties file or in the registry
>using the Preferences API and then use the property placeholder
>configurer to fill in the blanks at runtime.
>
>On other thing ..... if you wanted to be super smart and really show off
>heres a cool feature ....
>
><beans>
><if value="test" equals="test">
> <import resource="myImport1.xml"/>
></if>
>
> <bean ... />
>
>
></beans>
>
>
Better yet is for me to get myself in gear and start putting OGNL
support into Spring for 1.3. Then it would be:
<beans>
<if condition="somevalue == 1">
<import resource="myImport1.xml"/>
</if>
</beans>
- Drew
--
+---------------------------------+
< Drew Davidson | OGNL Technology >
+---------------------------------+
| Email: dr...@og... /
| Web: http://www.ognl.org /
| Vox: (520) 531-1966 <
| Fax: (520) 531-1965 \
| Mobile: (520) 405-2967 \
+---------------------------------+
|