springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Anonymous CVS access via Eclipse 3.0M3

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

Mark,

There were severe problems with anonymous CVS on SF for months until some
time last month when they did an upgrade and I think things improved
noticeably.

I haven't tried anon access, but I've had no problems since upgrading to
Eclipse 3 m3, so I doubt that's your problem.

Regards,
Rod

----- Original Message ----- 
From: "Mark McNally" <mg...@ho...>
To: <spr...@li...>
Sent: Tuesday, September 16, 2003 6:34 PM
Subject: [Springframework-developer] Anonymous CVS access via Eclipse 3.0M3


> Hello,
>
> I am wondering if others are having problems with Anonymous CVS access of
> the springframework repository.
>
> I am not sure if the issue is with the repository, my cvs client (Eclipse)
> or something else. I am attempting access via Eclipse but nothing below
the
> head node appears in the Eclipse cvs browser. I see no error messages when
I
> refresh but still no content is visible. I also tried to connect with the
> Hibernate repository and experienced the same symptoms.
>
> I have had intermittent connectivity problems for awhile but, before
> upgrading to version 3.0M3 of Eclipse several days ago, I was usually able
> to pull down the files.  I may revert to back to version 2.1 and give it a
> try but thought I'd throw this out here first.
>
> My repository identification string looks like this:
>   :pserver:ano...@cv...:/cvsroot/springframework
>
>
> Rod, Thank you for writing such a great book. I refer to and recommend it
> often.
> Also, thanks to all who have continued to advance this elegant framework
and
> supporting documentation.
>
> Mark
>
> _________________________________________________________________
> Use custom emotions -- try MSN Messenger 6.0!
> http://www.msnmessenger-download.com/tracking/reach_emoticon
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Anonymous CVS access via Eclipse 3.0M3

[Mark M. <mg...@ho...>]

Hello,

I am wondering if others are having problems with Anonymous CVS access of 
the springframework repository.

I am not sure if the issue is with the repository, my cvs client (Eclipse) 
or something else. I am attempting access via Eclipse but nothing below the 
head node appears in the Eclipse cvs browser. I see no error messages when I 
refresh but still no content is visible. I also tried to connect with the 
Hibernate repository and experienced the same symptoms.

I have had intermittent connectivity problems for awhile but, before 
upgrading to version 3.0M3 of Eclipse several days ago, I was usually able 
to pull down the files.  I may revert to back to version 2.1 and give it a 
try but thought I'd throw this out here first.

My repository identification string looks like this:
  :pserver:ano...@cv...:/cvsroot/springframework


Rod, Thank you for writing such a great book. I refer to and recommend it 
often.
Also, thanks to all who have continued to advance this elegant framework and 
supporting documentation.

Mark

_________________________________________________________________
Use custom emotions -- try MSN Messenger 6.0! 
http://www.msnmessenger-download.com/tracking/reach_emoticon

Re: [Springframework-developer] SimpleNamingContext should be usable with other providers around

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

How about I modify StaticListableBeanFactory, so it can optionally be 
constructed with the HashMap access being synchronized, and create an 
accessor class which returns a singleton instance of 
StaticListableBeanFactory?


Rod Johnson wrote:

>Colin,
>
>If you want to implement such an approach, please do and submit it for
>discussion, along with how you're using it.
>
>Regards,
>Rod
>
>----- Original Message ----- 
>From: "Colin Sampaleanu" <col...@ex...>
>To: "jürgen höller [werk3AT]" <jue...@we...>
>Cc: <spr...@li...>
>Sent: Tuesday, September 16, 2003 2:45 PM
>Subject: Re: [Springframework-developer] SimpleNamingContext should be
>usable with other providers around
>
>
>  
>
>>jürgen höller [werk3AT] wrote:
>>
>>    
>>
>>>Let's factor out the anonymous inner class from
>>>      
>>>
>SimpleNamingContextBuilder.createInitialContextFactory to a separate
>SimpleNamingContextFactory class. This should allow for using it in the way
>you intended.
>  
>
>>>Using a singleton bean factory should work too. You could also implement
>>>      
>>>
>your own custom singleton that loads whatever BeanFactory type you need.
>  
>
>>>      
>>>
>>I was being lazy. Easiest thing for me to do is just create a singleton
>>that returns an instance of StaticSingletonBeanFactory. But I think a
>>class like this (similar to BeanFactoryBootstrap except it would return
>>StaticSingletonBeanFactory) would be handy to have built-in.
>>
>>And for the record, I am not trying to subvert IOC here :-).  What I
>>actually want to do (which I will get to in another message) is link up
>>several ApplicationContext instances which are loaded in different
>>layers, and I need a place to store them temporarilly as they get
>>    
>>
>created...
>  
>

Re: [Springframework-developer] SimpleNamingContext should be usable with other providers around

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

Colin Sampaleanu wrote:

> jürgen höller [werk3AT] wrote:
>
>> Let's factor out the anonymous inner class from 
>> SimpleNamingContextBuilder.createInitialContextFactory to a separate 
>> SimpleNamingContextFactory class. This should allow for using it in 
>> the way you intended.
>>
>> Using a singleton bean factory should work too. You could also 
>> implement your own custom singleton that loads whatever BeanFactory 
>> type you need. 
>
> I was being lazy. Easiest thing for me to do is just create a 
> singleton that returns an instance of StaticSingletonBeanFactory. But 
> I think a class like this (similar to BeanFactoryBootstrap except it 
> would return StaticSingletonBeanFactory) would be handy to have built-in.

Of course, I meant StaticListableBeanFactory here, not 
StaticSingletonBeanFactory...

>
> And for the record, I am not trying to subvert IOC here :-).  What I 
> actually want to do (which I will get to in another message) is link 
> up several ApplicationContext instances which are loaded in different 
> layers, and I need a place to store them temporarilly as they get 
> created...

Re: [Springframework-developer] SimpleNamingContext should be usable with other providers around

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

Colin,

If you want to implement such an approach, please do and submit it for
discussion, along with how you're using it.

Regards,
Rod

----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: "jürgen höller [werk3AT]" <jue...@we...>
Cc: <spr...@li...>
Sent: Tuesday, September 16, 2003 2:45 PM
Subject: Re: [Springframework-developer] SimpleNamingContext should be
usable with other providers around


> jürgen höller [werk3AT] wrote:
>
> >Let's factor out the anonymous inner class from
SimpleNamingContextBuilder.createInitialContextFactory to a separate
SimpleNamingContextFactory class. This should allow for using it in the way
you intended.
> >
> >Using a singleton bean factory should work too. You could also implement
your own custom singleton that loads whatever BeanFactory type you need.
> >
> >
> I was being lazy. Easiest thing for me to do is just create a singleton
> that returns an instance of StaticSingletonBeanFactory. But I think a
> class like this (similar to BeanFactoryBootstrap except it would return
> StaticSingletonBeanFactory) would be handy to have built-in.
>
> And for the record, I am not trying to subvert IOC here :-).  What I
> actually want to do (which I will get to in another message) is link up
> several ApplicationContext instances which are loaded in different
> layers, and I need a place to store them temporarilly as they get
created...
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] SimpleNamingContext should be usable with other providers around

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

jürgen höller [werk3AT] wrote:

>Let's factor out the anonymous inner class from SimpleNamingContextBuilder.createInitialContextFactory to a separate SimpleNamingContextFactory class. This should allow for using it in the way you intended.
> 
>Using a singleton bean factory should work too. You could also implement your own custom singleton that loads whatever BeanFactory type you need.
>  
>
I was being lazy. Easiest thing for me to do is just create a singleton 
that returns an instance of StaticSingletonBeanFactory. But I think a 
class like this (similar to BeanFactoryBootstrap except it would return 
StaticSingletonBeanFactory) would be handy to have built-in.

And for the record, I am not trying to subvert IOC here :-).  What I 
actually want to do (which I will get to in another message) is link up 
several ApplicationContext instances which are loaded in different 
layers, and I need a place to store them temporarilly as they get created...

RE: [Springframework-developer] SimpleNamingContext should be usable with other providers around

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

TGV0J3MgZmFjdG9yIG91dCB0aGUgYW5vbnltb3VzIGlubmVyIGNsYXNzIGZyb20gU2ltcGxlTmFt
aW5nQ29udGV4dEJ1aWxkZXIuY3JlYXRlSW5pdGlhbENvbnRleHRGYWN0b3J5IHRvIGEgc2VwYXJh
dGUgU2ltcGxlTmFtaW5nQ29udGV4dEZhY3RvcnkgY2xhc3MuIFRoaXMgc2hvdWxkIGFsbG93IGZv
ciB1c2luZyBpdCBpbiB0aGUgd2F5IHlvdSBpbnRlbmRlZC4NCiANClVzaW5nIGEgc2luZ2xldG9u
IGJlYW4gZmFjdG9yeSBzaG91bGQgd29yayB0b28uIFlvdSBjb3VsZCBhbHNvIGltcGxlbWVudCB5
b3VyIG93biBjdXN0b20gc2luZ2xldG9uIHRoYXQgbG9hZHMgd2hhdGV2ZXIgQmVhbkZhY3Rvcnkg
dHlwZSB5b3UgbmVlZC4NCiANCkp1ZXJnZW4NCiANCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tIA0KCUZyb206IENvbGluIFNhbXBhbGVhbnUgW21haWx0bzpjb2xpbm1sMUBleGlzLmNvbV0g
DQoJU2VudDogVHVlIDkvMTYvMjAwMyAxMjoxNiBBTSANCglUbzogc3ByaW5nZnJhbWV3b3JrLWRl
dmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQoJQ2M6IA0KCVN1YmplY3Q6IFtTcHJpbmdm
cmFtZXdvcmstZGV2ZWxvcGVyXSBTaW1wbGVOYW1pbmdDb250ZXh0IHNob3VsZCBiZSB1c2FibGUg
d2l0aCBvdGhlciBwcm92aWRlcnMgYXJvdW5kDQoJDQoJDQoJIA0KDQo=

[Springframework-developer] Newbie

[Glenn A. T. <gth...@cd...>]

Hey folks,
I'm a newbie.
My Name is Glenn Thompson (gat).
While trying to get the petclinic sample app running against MySQL 4.1.0 
alpha, I ran into a few problems.
I figured I should share what I did to get it to work.:

1.  The supplied initDB.txt script fails to work under 4.0.14 and 4.1.0.
2.  I have attached a new script which will work for 4.0.14, 4.1.0 and 
uses InnoDB for the non Sequence tables.  It's the only table type that 
supports foreign keys.
3.  I had to change the name of the "types" table.  "types" is a 
reserved word under newer versions of MySQL.  I renamed it "pet_types" 
and the sequence table "pet_types_seq".  
4.  Because of item number three, AbstractJdbcClinic.java had to be 
changed.  See Attached.  MysqlClinic didn't have to be changed as the 
types sequence is not currently used by the app.  At least as far as I 
could see.
5.  You may want to add a commented out "clinic" bean to the 
applicationContext.xml that references MysqlClinic.  I  had it running 
(and blowing up against) Mysql using the HsqlClinic business object.  It 
took me a little bit to figure out what I had done wrong.  Thank god for 
stack traces:-)
6.  I was unable to get J/connector 3.1.x working.  Not sure why.  I 
used 3.0.8
7.  Under 4.1.0 the password handling has changed and is a little funky. 
 I had problems getting connections. Read the MySQL release notes.

Questions:
1.  Has anyone tried to make the "setupDB task" create the DB when 
"useMYSQL" is selected?  I was just wondering if there was something 
specific that kept it from being added to the task.
2.  If I have other changes should I submit them as patches? If so, 
which format do you folks prefer?

Thanks,
gat

PS Two thumbs up on J2EE D&D Rod!

[Springframework-developer] SimpleNamingContext should be usable with other providers around

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

I was trying to use SimpleNamingContext in a J2EE envioronment, but it 
this is not possible since it registers itself in the activate call
  NamingManager.setInitialContextFactoryBuilder(this);

All I want is a simple memory based jndi provider. If there existed a 
SimpleNamingContextFactory class (essentially the same as what is 
produced by createInitialContextFactory in the builder, then I could use 
it as a secondary JNDI provider:
      Hashtable env = new Hashtable();
      env.put(Context.INITIAL_CONTEXT_FACTORY, 
SimpleNamingFactory.class.getName());
      InitialContext ctx = new InitialContext(env);

Now all I want to do is stick a few objects in a well know location (and 
they're not serializable so I can't use normal JNDI, but I am in the 
same vm, so barring some classloading issues, a singleton mechanism of 
any sort is fine).

So if I could use a singleton beanfactory in the same fashion, that 
would also be ok. As far as I can tell though, the BootStrap method to 
get a singleton bean factory will return one that is loaded from the 
classpath. I know I could cast it to ListableBeanFactoryImpl, but that 
doesn't feel too clean...

RE: [Springframework-developer] NPE in JavaMailSender.send

[Kopylenko, D. <dko...@ac...>]

Thanks Christophe. Fixed :-)

Regards,
Dmitriy.

-----Original Message-----
From: Christophe Vanfleteren [mailto:c.v...@pa...] 
Sent: Sunday, September 14, 2003 8:38 PM
To: spr...@li...
Subject: [Springframework-developer] NPE in JavaMailSender.send


Hi,

I discovered a problem with the JavaMailSender class.
When you don't have any CC adresses set, you'll get a NPE while composing
the JavaMail message (the MailCC array is never initialized, and it
shouldn't have to be set explicitly to an empty array if there are no CC's).

This is the fix:

--- JavaMailSender.java	10 Sep 2003 00:14:54 -0000	1.1
+++ JavaMailSender.java	15 Sep 2003 00:32:34 -0000
@@ -47,7 +47,7 @@ public class JavaMailSender implements M
 			message.setText(mailSettings.getMailText());
 			message.setFrom(new
InternetAddress(mailSettings.getMailFrom()));
 			message.addRecipient(Message.RecipientType.TO, new
InternetAddress(mailSettings.getMailTo()));
-			if (mailSettings.getMailCc().length > 0) {
+			if (mailSettings.getMailCc() != null) {
 				for (int i = 0; i <
mailSettings.getMailCc().length; i++)
 
message.addRecipient(Message.RecipientType.CC, new
InternetAddress(mailSettings.getMailCc()[i]));
 			}

-- 
Kind regards,
Christophe Vanfleteren




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] NPE in JavaMailSender.send

[Christophe V. <c.v...@pa...>]

Hi,

I discovered a problem with the JavaMailSender class.
When you don't have any CC adresses set, you'll get a NPE while composing the JavaMail message (the MailCC array is never initialized, and it shouldn't have to be set explicitly to an empty array if there are no CC's).

This is the fix:

--- JavaMailSender.java	10 Sep 2003 00:14:54 -0000	1.1
+++ JavaMailSender.java	15 Sep 2003 00:32:34 -0000
@@ -47,7 +47,7 @@ public class JavaMailSender implements M
 			message.setText(mailSettings.getMailText());
 			message.setFrom(new InternetAddress(mailSettings.getMailFrom()));
 			message.addRecipient(Message.RecipientType.TO, new InternetAddress(mailSettings.getMailTo()));
-			if (mailSettings.getMailCc().length > 0) {
+			if (mailSettings.getMailCc() != null) {
 				for (int i = 0; i < mailSettings.getMailCc().length; i++)
 					message.addRecipient(Message.RecipientType.CC, new InternetAddress(mailSettings.getMailCc()[i]));
 			}

-- 
Kind regards,
Christophe Vanfleteren

Re: [Springframework-developer] Spring scheduler?

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

Sounds good to me.

----- Original Message ----- 
From: "Kopylenko, Dmitry" <dko...@su...>
To: <al...@jt...>; "'Ivan Ristic'" <iv...@we...>; "'Colin
Sampaleanu'" <col...@ex...>
Cc: <spr...@li...>
Sent: Friday, September 12, 2003 5:23 PM
Subject: RE: [Springframework-developer] Spring scheduler?


> > I think that might be the best way to do things. We've done it with
> > views and are doing it with persistence, so why not do it with
schedulers
> as well...
>
> So, if we take that approach, the first thing would be to design a
> "Scheduler" strategy interface which then could be implemented by
different
> "wrappers" around existing implementations. What everybody thinks?
>
> Regards,
> Dmitriy.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Spring scheduler?

[Ivan R. <iv...@we...>]

> Exactly! But I think the list of requirements still needs to be made,
> reflecting people's experiences with schedulers...


My scheduler requirements are given below. These are
based on the implementation I've started some time ago.
This is not an attempt to define and replace an
"enterprise scheduler". For a nice example of an
enterprise class scheduler have a look at Flux,
http://www.simscomputing.com/.


Scheduler requirements
======================

Immediate
---------

* Easy to use (gentle learning curve)
* Non intrusive (any object method can be scheduled)
* Support for persistent and non-persistent tasks
* Crontab compatible syntax (see "man crontab")
* Support for runnable interfaces
* Support for any object method, with our without parameters

* Spring support, scheduling directly from the configuration file
* Spring support, events to be scheduled

* Pluggable persistence modules
* File system storage module (crontab compatible)

* Changes to task data in the container will be picked up by the
   engine

* Support for task launchers, eg, execute native binaries, RMI,
   EJB, XMLRPC, SOAP, etc.


Other
-----

* Support for seconds (crontab does not support resolution finer
   than minutes)
* JDBC storage module
* Misc. launcher implementations
* Persisting information between tasks

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

RE: [Springframework-developer] Spring scheduler?

[Alef A. \(JTeam\) <al...@jt...>]

> I think that might be the best way to do things. We've done it with
> views and are doing it with persistence, so why not do it with
schedulers
as well...

> So, if we take that approach, the first thing would be to design a
> "Scheduler" strategy interface which then could be implemented by
different
> "wrappers" around existing implementations. What everybody thinks?

Exactly! But I think the list of requirements still needs to be made,
reflecting people's experiences with schedulers...

Alef

RE: [Springframework-developer] Spring scheduler?

[Kopylenko, D. <dko...@ac...>]

> I think that might be the best way to do things. We've done it with 
> views and are doing it with persistence, so why not do it with schedulers
as well...

So, if we take that approach, the first thing would be to design a
"Scheduler" strategy interface which then could be implemented by different
"wrappers" around existing implementations. What everybody thinks?

Regards,
Dmitriy.

RE: [Springframework-developer] Spring scheduler?

[Alef A. \(JTeam\) <al...@jt...>]

> In this
> respect, maybe what makes sense is some classes to integrate Quartz
into 
> Spring...

   > I plan to approach this issue from a point of view of Spring, make
a list
   > of functionality we may need (which will be easy since I am doing
   > a project where this functionality will be required). Only after
   > that we can discuss whether an existing package can be integrated.

Well, that's a good thing to do anyway.

   > Or, perhaps, implementations could be pluggable.

I think that might be the best way to do things. We've done it with 
views and are doing it with persistence, so why not do it with
schedulers as well...

Alef






-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring scheduler?

[Rajeev K. <Ra...@cu...>]

I agree.  We should take advantage of existing open source projects that
already implement this feature, and not re-invent the wheel.

Here are couple of more resources that implement this feature:

http://jcrontab.sourceforge.net

http://jakarta.apache.org/turbine/index.html



Rajeev Kaul

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: "Ivan Ristic" <iv...@we...>;
<spr...@li...>
Sent: Friday, September 12, 2003 7:01 AM
Subject: Re: [Springframework-developer] Spring scheduler?


> Why not just take advantage of Quartz? It's free, and has an Apache/BSD
> style license.
>   http://www.part.net/quartz.html
>   http://www.part.net/quartz_features.html
>
> We've been using it for a while with good results. Personally, I don't
> think it's a great idea to add functionality to Spring which duplicates
> existing projects that are out there and that have open licenses,
> _unless_ the Spring implementation has some clear advantages. In this
> respect, maybe what makes sense is some classes to integrate Quartz into
> Spring...
>
> Regards,
> Colin
>
>
> Ivan Ristic wrote:
>
> >
> > [Note: I sent this email yesterday but I did not see it arrive to
> >  the mailing list. So here is it again.]
> >
> >
> > As part of my project I am building a (simple but capable) cron-like
> > scheduler. Do you think there is a place for it in the Spring
> > framework? It will support both persistent and non-persistent
scheduling.
> >
> > I think the scheduler itself should be a JavaBean, capable of
> > executing a given method (with or without parameters) on
> > an object, according to the supplied schedule.
> >
> > Another possibility is to have the scheduler integrated into the
> > context but I'm not sure how smart that would be.
> >
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring scheduler?

[Ivan R. <iv...@we...>]

Colin Sampaleanu wrote:
> Why not just take advantage of Quartz? It's free, and has an Apache/BSD 
> style license.
>  http://www.part.net/quartz.html
>  http://www.part.net/quartz_features.html

   I reviewed Quartz for my project before I decided to wrap my own,
   and decided against it because it was simply too complex and too
   intrusive for my taste (and it didn't have/does not have file system
   persistence). I don't think there is anything wrong with it (besides,
   I did not program in it I just read the documentation). My friend
   used to say "Never use a cannon to accomplish what you could with a
   stick".


> We've been using it for a while with good results. Personally, I don't 
> think it's a great idea to add functionality to Spring which duplicates 
> existing projects that are out there and that have open licenses, 
> _unless_ the Spring implementation has some clear advantages.

   Agreed.


> In this 
> respect, maybe what makes sense is some classes to integrate Quartz into 
> Spring...

   I don't think there's an easy way to bring Quartz to Spring because
   Quartz requires you to implement a particular interface and go with
   its triggers. Also, it has its own events.

   But I don't want this to turn into a "battle" about Quartz. I plan
   to approach this issue from a point of view of Spring, make a list
   of functionality we may need (which will be easy since I am doing
   a project where this functionality will be required). Only after
   that we can discuss whether an existing package can be integrated.
   Or, perhaps, implementations could be pluggable.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [Springframework-developer] Spring scheduler?

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

Why not just take advantage of Quartz? It's free, and has an Apache/BSD 
style license.
  http://www.part.net/quartz.html
  http://www.part.net/quartz_features.html

We've been using it for a while with good results. Personally, I don't 
think it's a great idea to add functionality to Spring which duplicates 
existing projects that are out there and that have open licenses, 
_unless_ the Spring implementation has some clear advantages. In this 
respect, maybe what makes sense is some classes to integrate Quartz into 
Spring...

Regards,
Colin


Ivan Ristic wrote:

>
> [Note: I sent this email yesterday but I did not see it arrive to
>  the mailing list. So here is it again.]
>
>
> As part of my project I am building a (simple but capable) cron-like
> scheduler. Do you think there is a place for it in the Spring
> framework? It will support both persistent and non-persistent scheduling.
>
> I think the scheduler itself should be a JavaBean, capable of
> executing a given method (with or without parameters) on
> an object, according to the supplied schedule.
>
> Another possibility is to have the scheduler integrated into the
> context but I'm not sure how smart that would be.
>

RE: [Springframework-developer] Spring scheduler?

[Trevor C. <pr...@se...>]

We're currently using Quartz which is another very good/stable open-source
and free scheduler (see http://www.part.net/quartz.html).

Trevor D. Cook


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Ivan Ristic
Sent: September 12, 2003 7:48 AM
To: Rod Johnson
Cc: spr...@li...
Subject: Re: [Springframework-developer] Spring scheduler?


Rod Johnson wrote:
> Yes I think this could be useful. I could envisage uses for it.

   I will study Spring coding and design standards and
   come back with more details.


> I don't quite understand the "integration with the context" you propose.
> Couldn't the scheduler be a BeanFactoryAware bean in a context, and its
> setBeanFactory() method give it access to whatever other beans it needs
and
> also kick off its timer/whatever?
>
> Of course it could be configured by its JavaBean properties.

   Yes. But there is also a case where you want to schedule events
   from your code. There are three ways to achieve this:

   1) Explicit configuration, create a scheduler and then give
      its reference to every bean that needs it.

   2) Have the scheduler as a shared object; other beans have to
      be ApplicationContext aware, and use a call to sharedObject()
      to retrieve the scheduler reference.

   3) Add getScheduler() method to ApplicationContext. I actually
      don't like this approach. I only mentioned it because it is
      a possibility.

   From my point of view, 1 and 2 are acceptable options. The third
   option would lead to a fat app. context, and I don't see real
   benefit there.

   Maybe Spring should define certain names (with or without
   a namespace) to be reserved for certain services, e.g.
   "service.scheduler". People will certainly do this
   themselves, perhaps if we do it on a framework level we
   can have greater "portability".

--
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/2003

Re: [Springframework-developer] Spring scheduler?

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

Hi,

You might want to check out Doug Lea's Scheduler in his util.concurrent
package for a base implementation, maybe wrapped to be more JavaBean
friendly.  The J2EE timer service in JBoss might be a good place to look
as well....

Services are typically singletons, so going to an
ApplicationContext/BeanFactory to get a reference to it should be
sufficient I would think.

BTW, I am following up on Jurgen's advice regarding service lifecycles,
modifying my implementation.  The scheduler could be an out of the box
service, since it should probably only start after all beans have been
wired.

- Mark


> Rod Johnson wrote:
>> Yes I think this could be useful. I could envisage uses for it.
>
>    I will study Spring coding and design standards and
>    come back with more details.
>
>
>> I don't quite understand the "integration with the context" you propose.
>> Couldn't the scheduler be a BeanFactoryAware bean in a context, and its
>> setBeanFactory() method give it access to whatever other beans it needs
>> and
>> also kick off its timer/whatever?
>>
>> Of course it could be configured by its JavaBean properties.
>
>    Yes. But there is also a case where you want to schedule events
>    from your code. There are three ways to achieve this:
>
>    1) Explicit configuration, create a scheduler and then give
>       its reference to every bean that needs it.
>
>    2) Have the scheduler as a shared object; other beans have to
>       be ApplicationContext aware, and use a call to sharedObject()
>       to retrieve the scheduler reference.
>
>    3) Add getScheduler() method to ApplicationContext. I actually
>       don't like this approach. I only mentioned it because it is
>       a possibility.
>
>    From my point of view, 1 and 2 are acceptable options. The third
>    option would lead to a fat app. context, and I don't see real
>    benefit there.
>
>    Maybe Spring should define certain names (with or without
>    a namespace) to be reserved for certain services, e.g.
>    "service.scheduler". People will certainly do this
>    themselves, perhaps if we do it on a framework level we
>    can have greater "portability".
>
> --
> ModSecurity (http://www.modsecurity.org)
> [ Open source IDS for Web applications ]
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

RE: [Springframework-developer] wrapping an interceptor and Hibernate specific TransactionProxyFactoryBean

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

SGkgQ29saW4sDQogDQpZb3VyIGlzc3VlIGlzIGNhdXNlZCBieSB0aGUgcmVsaWFuY2Ugb2YgeW91
ciBIaWJlcm5hdGUgYWNjZXNzIGNvZGUgb24gSGliZXJuYXRlSW50ZXJjZXB0b3IgZm9yIGNvcnJl
Y3QgcmVzb3VyY2Ugb3BlbmluZyBhbmQgY2xvc2luZy4gWW91IHNob3VsZCBhcHBseSBIaWJlcm5h
dGVJbnRlcmNlcHRvciBldmVuIHdoZW4gdXNpbmcgSGliZXJuYXRlVHJhbnNhY3Rpb25NYW5hZ2Vy
LCB0byBiZSBhYmxlIHRvIHN3aXRjaCB0byBKdGFUcmFuc2FjdGlvbk1hbmFnZXIgd2l0aG91dCBo
YXNzbGUuDQogDQpOb3RlIHRoYXQgd2hlbiB1c2luZyBIaWJlcm5hdGVUZW1wbGF0ZSB3aXRoIGFs
bG93Q3JlYXRlPXRydWUgKHRoZSBkZWZhdWx0KSwgYSBuZXcgU2Vzc2lvbiB3aWxsIGF1dG9tYXRp
Y2FsbHkgZW5saXN0IGl0c2VsZiB3aXRoIHRoZSB0cmFuc2FjdGlvbiBzeW5jaHJvbml6YXRpb24g
Y2FwYWJpbGl0aWVzIG9mIEp0YVRyYW5zYWN0aW9uTWFuYWdlcjogSXQgd2lsbCBiZSBjcmVhdGVk
IG9uIGZpcnN0IGFjY2VzcywgcmV1c2VkIHRocm91Z2hvdXQgdGhlIGN1cnJlbnQgdHJhbnNhY3Rp
b24sIGFuZCBjbG9zZWQgb24gdHJhbnNhY3Rpb24gY29tcGxldGlvbi4gVGhpcyBndWFyYW50ZWVz
IGNvcnJlY3QgSlZNLWxldmVsIHJlYWQtd3JpdGUgY2FjaGluZyB3aXRoIEpUQSwgYW5kIHNlYW1s
ZXNzIHN3aXRjaGluZyBiZXR3ZWVuIEhpYmVybmF0ZVRyYW5zYWN0aW9uTWFuYWdlciBhbmQgSnRh
VHJhbnNhY3Rpb25NYW5hZ2VyLg0KIA0KSW4geW91ciBjYXNlLCBJIHdvdWxkIGluZGVlZCBoYXZl
IHN1Z2dlc3RlZCB0byBnbyB0aGUgc3RhbmRhcmQgUHJveHlGYWN0b3J5QmVhbiByb3V0ZSBhbmQg
YXBwbHkgYSBIaWJlcm5hdGVJbnRlcmNlcHRvciBhZnRlciB0aGUgVHJhbnNhY3Rpb25JbnRlcmNl
cHRvciAoYWZ0ZXIgaXMgc2VtYW50aWNhbGx5IGNsZWFyZXIgdGhhbiBiZWZvcmUsIElNTykuIFBy
b3h5RmFjdG9yeUJlYW4gaXMgdGhlIGNvcnJlY3QgY2hvaWNlIGZvciBhcHBseWluZyBtdWx0aXBs
ZSBpbnRlcmNlcHRvcnMuIFRyYW5zYWN0aW9uUHJveHlGYWN0b3J5QmVhbiBpcyBqdXN0IG1lYW50
IGZvciBkZWNsYXJhdGl2ZSB0cmFuc2FjdGlvbiBtYW5hZ2VtZW50IHdpdGhvdXQgd29ycnlpbmcg
YWJvdXQgQU9QIGNvbmNlcHRzLg0KIA0KT2J2aW91c2x5LCBUcmFuc2FjdGlvblByb3h5RmFjdG9y
eUJlYW4gY291bGQgYmUgZXh0ZW5kZWQgdG8gc3VwcG9ydCBhZGRpdGlvbmFsIGludGVyY2VwdG9y
cyBmb3IgaXRzIHRhcmdldCBiZWFuLiBJIHdvdWxkIHJlc3RyaWN0IHRoaXMgdG8gdHJhbnNhY3Rp
b25hbCBtZXRob2RzIHRob3VnaDogRXhlY3V0aW5nIG90aGVyIG1ldGhvZHMgd2l0aCBhIEhpYmVy
bmF0ZSBTZXNzaW9uIGlzIHJlYWxseSBub3QgdGhlIHRhc2sgb2YgVHJhbnNhY3Rpb25Qcm94eUZh
Y3RvcnkgQmVhbiAtIEkgY29uc2lkZXIgYSBnZW5lcmljIFByb3h5RmFjdG9yeUJlYW4gYXBwcm9w
cmlhdGUgaGVyZS4gQW5kIHlvdSBjYW4gYWx3YXlzIGRlZmluZSBtZXRob2RzIGFzIHRyYW5zYWN0
aW9uYWwgYnV0IHdpdGggcHJvcGFnYXRpb24gInN1cHBvcnRzIiBpbnN0ZWFkIG9mICJyZXF1aXJl
ZCIuDQogDQpTdWNoIGEgaG9vayBpbiBUcmFuc2FjdGlvblByb3h5RmFjdG9yeUJlYW4gc2hvdWxk
IHByb2JhYmx5IGJlIG1vZGVsbGVkIGFzICJhZGRpdGlvbmFsSW50ZXJjZXB0b3JzIiBwcm9wZXJ0
eSwgdGFraW5nIGEgbGlzdCBvZiBJbnRlcmNlcHRvciBpbnN0YW5jZXMsIGdldHRpbmcgYXBwbGll
ZCBhZnRlciB0aGUgaW1wbGljaXQgVHJhbnNhY3Rpb25JbnRlcmNlcHRvciBmb3IgdHJhbnNhY3Rp
b25hbCBtZXRob2RzLiBUaGlzIGNhbiB0YWtlIGEgSGliZXJuYXRlSW50ZXJjZXB0b3Igb3IgSmRv
SW50ZXJjZXB0b3Igb3IgdGhlIGxpa2UuIEFnYWluLCBhbiBhZGRpdGlvbmFsIEhpYmVybmF0ZUlu
dGVyY2VwdG9ycyBkb2Vzbid0IGh1cnQgZXZlbiB3aXRoIEhpYmVybmF0ZVRyYW5zYWN0aW9uTWFu
YWdlciAtIGl0IHdpbGwgc2ltcGx5IHBhcnRpY2lwYXRlIGluIHRoZSBleGlzdGluZyB0aHJlYWQt
YmluZGluZy4NCiANCkp1ZXJnZW4NCiANCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0K
CUZyb206IENvbGluIFNhbXBhbGVhbnUgW21haWx0bzpjb2xpbm1sMUBleGlzLmNvbV0gDQoJU2Vu
dDogVGh1IDkvNC8yMDAzIDExOjEwIFBNIA0KCVRvOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVy
QGxpc3RzLnNvdXJjZWZvcmdlLm5ldCANCglDYzogDQoJU3ViamVjdDogW1NwcmluZ2ZyYW1ld29y
ay1kZXZlbG9wZXJdIHdyYXBwaW5nIGFuIGludGVyY2VwdG9yIGFuZCBIaWJlcm5hdGUgc3BlY2lm
aWMgVHJhbnNhY3Rpb25Qcm94eUZhY3RvcnlCZWFuDQoJDQoJDQoNCglJIHdhcyB1c2luZyB0aGUg
VHJhbnNhY3Rpb25Qcm94eUZhY3RvcnlCZWFuIHdpdGggdGhlDQoJSGliZXJuYXRlVHJhbnNhY3Rp
b25NYW5hZ2VyLCBidXQgd2hlbiBJIHN3aXRjaGVkIHRvIHRoZQ0KCUpUQVRyYW5zYWN0aW9uTWFu
YWdlciwgZ290IGJpdHRlbiBieSB0aGUgZmFjdCB0aGF0IEkgbm8gbG9uZ2VyIGhhZA0KCWFueXRo
aW5nIGNyZWF0aW5nIGEgSGliZXJuYXRlIHNlc3Npb24gYW5kIGJpbmRpbmcgaXQgdG8gdGhlIGN1
cnJlbnQNCgl0aHJlYWQsIGFzIEhpYmVybmF0ZVRyYW5zYWN0aW9uTWFuYWdlciB1c2VkIHRvIGRv
IGJ5IGRlZmF1bHQuDQoJDQoJT25lIHZlcmJvc2Ugc29sdXRpb24gd291bGQgaGF2ZSBiZWVuIHRv
IGhhdmUgZ29uZSBiYWNrIHRvIHRoZSBvbGQNCglQcm94eUZhY3RvcnlCZWFuIG1lY2hhbmlzbSBm
b3IgaGFuZGxpbmcgdHJhbnNhY3Rpb25zLCBhbmQganVzdCBzdGFjayBhDQoJSGliZXJuYXRlSW50
ZXJjZXB0b3IgaW4gZnJvbnQgb2YgdGhlIHRyYW5zYWN0aW9uIGludGVyY2VwdG9yLg0KCQ0KCUkg
ZGVjaWRlZCBpbnN0ZWFkIHRvIG1ha2UgYSBIaWJlcm5hdGUgc3BlY2lmaWMgdmVyaXNvbiBvZg0K
CVRyYW5zYWN0aW9uUHJveHlGYWN0b3J5QmVhbi4gQWxsIGl0IGRvZXMgaXMgdGFrZSBhIG5ldw0K
CUhpYmVybmF0ZUludGVyY2VwdG9yIHByb3BlcnR5LCBhbmQgaW4gYWZ0ZXJQcm9wZXJ0aWVzU2V0
IGFkZCB0aGUNCglpbnRlcmNlcHRvciBiZWZvcmUgdGhlIHRyYW5zYWN0aW9uIG9uZSAoaG93ZXZl
ciwgdW5saWtlIHRoZSB0cmFuc2FjdGlvbg0KCW9uZSwgaXQgd2lsbCBleGVjdXRlIG9uIGFsbCBp
bnZvY2F0aW9ucywgc2luY2UgeW91IG1heSB3YW50IHRvIHJ1biBzb21lDQoJbWV0aG9kcyB3aXRo
IGEgaGliZXJuYXRlIHNlc3Npb24sIGJ1dCBubyB0cmFuc2FjdGlvbnMuDQoJICAgICAgICAvLyBh
bGx3YXlzIGludm9rZSB0aGUgSGliZXJuYXRlIEludGVyY2VwdG9yDQoJICAgICAgICBhZGRJbnRl
cmNlcHRvcihoaWJlcm5hdGVJbnRlcmNlcHRvcik7DQoJICAgICAgICAuLi4gZXhpc3RpbmcgY29k
ZSB0byBzZXQgdXAgdGhlIFRyYW5zYWN0aW9uIGludGVyY2VwdG9yDQoJDQoJTm93IG15IHF1ZXN0
aW9uczoNCgkxOiBpcyBpdCB3b3J0aCBjaGVja2luZyBzb21ldGhpbmcgbGlrZSB0aGlzIGluPyBJ
IG1hZGUgYSBjdXQgYW5kIHBhc3QNCgljb3B5IG9mIFRyYW5zYWN0aW9uUHJveHlGYWN0b3J5QmVh
biwgYW5kIGFkZGVkIHRoZSBuZXcgcHJvcGVydHkgYW5kDQoJbW9kaWZpZWQgdGhlIGFmdGVyUHJv
cGVydGllc1NldC4gT2J2aW91c2x5LCBJIGNvdWxkIGFsc28gaGF2ZSBqdXN0DQoJc3ViY2xhc3Nl
cyB0aGUgZXhpc3RpbmcgY2xhc3MgYW5kIG92ZXJyaWRlbiBhZnRlclByb3BlcnRpZXNTZXQuIFRo
YXQncw0KCXByb2JhYmx5IGEgYmV0dGVyIGNob2ljZSwgYnV0IG1heWJlIGEgYml0IG1vcmUgZGFu
Z2Vyb3VzIGlmIHNvbWV0aGluZw0KCWNoYW5nZXMgaW4gdGhlIHBhcmVudCBtZXRob2Qgd2hpY2gg
aXMgbm8gbG9uZ2VyIGNhbGxlZCBhdCBhbGwuDQoJMjogaXMgdGhlcmUgYSBiZXR0ZXIgd2F5IG9m
IGRvaW5nIHRoaXM/IEkgc3VwcG9zZWQgSSBjb3VsZCBoYXZlIHdyYXBwZWQNCgl0aGUgcHJveHkg
aW4gYW5vdGhlciBwcm94eSB0byBhZGQgdGhlIGhpYmVybmF0ZSBpbnRlcmNlcHRvci4gVGhpcyB3
b3VsZA0KCW5vdCBoYXZlIHJlcXVpcmVkIGFueSBjb2RlIGNoYW5nZXMsIGJ1dCB3b3VsZCBoYXZl
IG1hZGUgZm9yIGEgbG90IG1vcmUNCgl0eXBpbmcgaW4gdGhlIGNvbnRleHQuICBBbm90aGVyIG9w
dGlvbiB3b3VsZCBiZSB0byBhZGQgb3B0aW9uYWwgYmVmb3JlDQoJYW5kIGFmdGVyLCAnYWx3YXlz
IGludm9rZScgaW50ZXJjZXB0b3IgcHJvcGVydGllcyB0byB0aGUNCglUcmFuc2FjdGlvblByb3h5
RmFjdG9yeUJlYW4sIHNvIHNvbWV0aGluZyBsaWtlIHRoaXMgY2FuIGJlIGFkZGVkLg0KCQ0KCVJl
Z2FyZHMsDQoJQ29saW4NCgkNCgkNCgkNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJVGhpcyBzZi5uZXQgZW1haWwgaXMgc3BvbnNvcmVk
IGJ5OlRoaW5rR2Vlaw0KCVdlbGNvbWUgdG8gZ2VlayBoZWF2ZW4uDQoJaHR0cDovL3RoaW5rZ2Vl
ay5jb20vc2YNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQoJU3ByaW5nZnJhbWV3
b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglodHRwczovL2xpc3RzLnNvdXJj
ZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQoJDQoN
Cg==

Re: [Springframework-developer] Spring scheduler?

[Ivan R. <iv...@we...>]

Rod Johnson wrote:
> Yes I think this could be useful. I could envisage uses for it.

   I will study Spring coding and design standards and
   come back with more details.


> I don't quite understand the "integration with the context" you propose. 
> Couldn't the scheduler be a BeanFactoryAware bean in a context, and its
> setBeanFactory() method give it access to whatever other beans it needs and
> also kick off its timer/whatever?
> 
> Of course it could be configured by its JavaBean properties.

   Yes. But there is also a case where you want to schedule events
   from your code. There are three ways to achieve this:

   1) Explicit configuration, create a scheduler and then give
      its reference to every bean that needs it.

   2) Have the scheduler as a shared object; other beans have to
      be ApplicationContext aware, and use a call to sharedObject()
      to retrieve the scheduler reference.

   3) Add getScheduler() method to ApplicationContext. I actually
      don't like this approach. I only mentioned it because it is
      a possibility.

   From my point of view, 1 and 2 are acceptable options. The third
   option would lead to a fat app. context, and I don't see real
   benefit there.

   Maybe Spring should define certain names (with or without
   a namespace) to be reserved for certain services, e.g.
   "service.scheduler". People will certainly do this
   themselves, perhaps if we do it on a framework level we
   can have greater "portability".

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [Springframework-developer] Spring scheduler?

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

Yes I think this could be useful. I could envisage uses for it.

I don't quite understand the "integration with the context" you propose.
Couldn't the scheduler be a BeanFactoryAware bean in a context, and its
setBeanFactory() method give it access to whatever other beans it needs and
also kick off its timer/whatever?

Of course it could be configured by its JavaBean properties.

Regards,
Rod

----- Original Message -----
From: "Ivan Ristic" <iv...@we...>
To: <spr...@li...>
Sent: Friday, September 12, 2003 10:42 AM
Subject: [Springframework-developer] Spring scheduler?


>
> [Note: I sent this email yesterday but I did not see it arrive to
>   the mailing list. So here is it again.]
>
>
> As part of my project I am building a (simple but capable) cron-like
> scheduler. Do you think there is a place for it in the Spring
> framework? It will support both persistent and non-persistent scheduling.
>
> I think the scheduler itself should be a JavaBean, capable of
> executing a given method (with or without parameters) on
> an object, according to the supplied schedule.
>
> Another possibility is to have the scheduler integrated into the
> context but I'm not sure how smart that would be.
>
> --
> ModSecurity (http://www.modsecurity.org)
> [ Open source IDS for Web applications ]
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Spring scheduler?

[Ivan R. <iv...@we...>]

[Note: I sent this email yesterday but I did not see it arrive to
  the mailing list. So here is it again.]


As part of my project I am building a (simple but capable) cron-like
scheduler. Do you think there is a place for it in the Spring
framework? It will support both persistent and non-persistent scheduling.

I think the scheduler itself should be a JavaBean, capable of
executing a given method (with or without parameters) on
an object, according to the supplied schedule.

Another possibility is to have the scheduler integrated into the
context but I'm not sure how smart that would be.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]