I'm not a Tomcat developer, I'm an outside observer too, but I agree with Tim.
If you want such a feature, I think you have to implement such a package, which could be an optional additional package for Tomcat (like the apache commons packages, ... or other), and, why not, available in a tomcat add-ons site (just a thought too)... Your solution or the Jonathan Wilson's solution could be an issue ... if you run your webapp on a single tomcat. But if you run it on a cluster, perhaps you don't want your servlet running (at xx:yy) on each node; only on one node... For this need, a daemon will be better if you need to run your "servlet run-at" only once per webapp... For this reason, even if a lot of developpers need such a feature, I think Tomcat has nothing to implement for this : it is a servlet container, not a full J2EE container. On Thu, 3 Mar 2005 22:28:41 -0500 "Parsons Technical Services" <[EMAIL PROTECTED]> wrote: > And so the best way is to have a set of classes to add to your project that > add this feature. It then moves with the app and can be applied per app or > even as a jar in common lib for use by all apps. > > Tim, am I thinking right on this? > > Remember that Tomcat follows the spec which is developed and created by > others. So impossible is not an accurate statement. Anything is possible. > But this is not the forum to lobby. Tomcat nor Apache are the creators of > the spec. They only follow it. Now if you want to lobby these folks, fell > free to. You never know, it may be something that is being considered and > another voice may help. > > As for Tomcat if you start adding things that are not spec driven you open > yourself up for controversy and problems down the road. Just trying to > follow the spec can be a pain in itself, for each creator of a container > will interpret some areas differently. Knowing that you app will run on any > container because the container you run on follows the spec can be a big > load off a developers mind. Although I am not one of the developers working > on Tomcat, I think this is why you are seeing some of the changes that have > occurred in the last year. Tomcat is moving away from non spec features and > trying to tow a tighter line. NOTE: This is my opinion as an outside > observer. > > I know the developers sound a little rude or abrupt, but remember that is > many way their hands are tied. They are committed to building a reliable > product that is widely accepted and compatible/comparable to other > containers. To accomplish this they must do their best to follow the spec > for failure to do so would result in just that, failure. I am sure there are > tons of features and ideas that they would love to add, but can't because of > the spec. > > I have spoke up, many times, in defense of the wonderful folks who spend so > much of their time on Tomcat. I do this because it is one way that I can > contribute back. I do this not to belittle you or anyone else, but to inform > you and help you and others understand. > > These guys do a great job and I for one am very thankful. > > So if someone will write these classes, and someone will host them maybe we > can get a link off the Tomcat in the FAQ section??? Just a thought. > > > Doug > > ----- Original Message ----- > From: "Tim Funk" <[EMAIL PROTECTED]> > To: "Tomcat Users List" <tomcat-user@jakarta.apache.org> > Sent: Thursday, March 03, 2005 8:51 PM > Subject: Re: Equivalent of Resin "run-at" servlet configuration > > > > run-at is an extension to web.xml that is not portable across containers. > > That's why it will not be implemented. > > > > -Tim > > > > Aris Javier wrote: > > > >> No, meaning impossible? > >> > >> cause if it would be very beneficial to many then why > >> not change the specs to accommodate such service? > >> > >> Pardon me, maybe because I really don't understand the specs. > >> I was just thinking in a layman's way. > >> > >> Thanks > >> Aris > >> -----Original Message----- > >> From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: Friday, March 04, 2005 > >> 9:42 AM > >> To: Tomcat Users List > >> Subject: Re: Equivalent of Resin "run-at" servlet configuration > >> > >> no. (unless the spec says so) > >> > >> -Tim > >> > >> Aris Javier wrote: > >> > >>>If this is not supported in Tomcat, is there a way or a plan to have this > >>>kind of service? This would really be a big help to many developers. > >>> > >>>Just a thought > >>> > >>>Aris > >>> > >>>-----Original Message----- > >>>From: David Smith [mailto:[EMAIL PROTECTED] > >>>Sent: Thursday, March 03, 2005 9:34 PM > >>>To: Tomcat Users List > >>>Subject: Re: Equivalent of Resin "run-at" servlet configuration > >>> > >>>I think the Cocoon project has such a facility. I'm not sure how > >>>complicated it would be to pull out that functionality, but their work > >> > >> > >>>might be worth looking at for this. > >>> > >>>--David > >>> > >>>Parsons Technical Services wrote: > >>> > >>> > >>> > >>>>With all the questions and suggestions flying around, a question to the > >>>>other programmers: If one was to write a class for the purpose of > >>>>running classes at set times, what pitfalls would one need to watch > >>> > >>>for? > >>> > >>> > >>>>I have a class that loads on startup and runs a continuous loop that is > >>>>timed (sleeps, wakes up, does something, sleeps again). It runs fine, > >>>>but I know that it could be better. > >>>> > >>>>Any guidance or suggestions would be appreciated. And maybe we could > >>>>create an add-on and post it for use in apps that need such a device. > >>>> > >>>>Thanks > >>>> > >>>>Doug > >>>> > >>>> > >>>>----- Original Message ----- From: "Nikola Milutinovic" > >>>><[EMAIL PROTECTED]> > >>>>To: "Tomcat Users List" <tomcat-user@jakarta.apache.org> > >>>>Sent: Thursday, March 03, 2005 6:55 AM > >>>>Subject: Re: Equivalent of Resin "run-at" servlet configuration > >>>> > >>>> > >>>> > >>>> > >>>>>Subramanya Sastry wrote: > >>>>> > >>>>> > >>>>> > >>>>>>Hello, > >>>>>> > >>>>>>I am developing a Java web application, and one of the requirements is > >>>>>>to run a particular servlet periodically, or even at specified times. > >>>>>>Resin provides this ability via its "run-at" configuration element for > >>>>>>servlets in web.xml > >>>>>> > >>>>>>Example Resin configuration: > >>>>>> <servlet> > >>>>>> <servlet-name>download</servlet-name> > >>>>>> <servlet-class>DownloadNewsServlet</servlet-class> > >>>>>> <run-at period='360m'/> > >>>>>> </servlet> > >>>>>> > >>>>>>However, I haven't found an equivalent configuration for Tomcat. I > >>>>>>searched the web and was unsuccessful. So, any pointers as to how I > >>> > >>> > >>>>>>could achieve this for Tomcat would be appreciated. > >>>>>> > >>>>> > >>>>>There is none and shouldn't be any. I understand the need to run > >>>>>periodical tasks, but J2EE specification, prior to 1.4 has no such > >>>>>provisions. Further, Servlet/JSP specification has no such provision, > >>> > >>> > >>>>>even in J2EE 1.4. You'd be best advised to setup a cron-job to perform > >>>>>this periodic activity. There are several good HTTP client packages out > >>>>>there, Jakarta-Commons HTTPclient, to name one, that will help you in > >>>>>building the client side of your cron-job. > >>>>> > >>>>>Nix. > >>>>> > >>>>>--------------------------------------------------------------------- > >>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>>--------------------------------------------------------------------- > >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>> > >>> > >>>--------------------------------------------------------------------- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>>--------------------------------------------------------------------- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
