OK - that sounds reasonable. BTW, have you looked at Coconut for inspiration (we mentioned it on a thread way back)? Does it fit well with what you are trying to do? AFAIR, Coconut is also Java 5+.
I think the xdocs are pushed to the site maven's generate task. Need someone to chip in here who has actually done this before, though. "Jakarta Commons Developers List" <[EMAIL PROTECTED]> wrote: > > I figure that since pipeline is a brand-new project, there's no harm in > starting with it being only 1.5-compatible. I guess the risk of doing > this is that it will probably slow the community growth, but the general > approach I'm taking is to start with 1.5 and backport to a > 1.4-compatible branch if someone wants it. It's still a small enough > library and takes advantage of few enough java 1.5 features that a > backport would only take a couple of hours. > > Speaking of building community, I'm going to submit some new xdocs > through bugzilla here fairly soon, and it would be great if you could > help me with the process of getting them onto the commons site. If there > are new xdocs in CVS, do they get pushed up as part of the nightly > build, or is it a separate process? > > Thanks for your help, > > Kris > > > Rory Winston wrote: > > > Hi Kris, > > > > I just did a sample build and test with Maven - it works fine. My only > > question is - are you planning to make [pipeline] 1.5-compatible only > > from this point on, or do you also plan to make it 1.4-compatible as > > well? > > > > Cheers, > > Rory > > > > Kris Nuttycombe wrote: > > > >> I'm toying with making the sibling shutdown policy dependent upon the > >> StageDriver implementation, since that's where the policy is actually > >> implemented, and using a configuration parameter probably doesn't > >> provide a sufficient number of error handling policies for all the > >> possible use cases. Since each stage is associated with a StageDriver > >> and the class of the associated StageDriver is specified in the > >> configuration file, it makes it easy to set things up on a > >> stage-by-stage basis. The only problem with this idea is that it > >> doesn't separate error policy implementation from threading policy > >> implementation, so you're likely to get code duplication in (# of > >> threading policies * # of error policies) classes. > >> > >> As an aside, the commons-sandbox CVS has been updated with the most > >> current version of the pipeline code, so if you want to see the error > >> handling policy I'm talking about take a look at the WorkerThread > >> inner class here: > >> http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/pipeline/src/java/org/apache/commons/pipeline/impl/SingleThreadStageDriver.java?rev=1.1&view=auto > >> > >> > >> > >> Kris > >> > >> Ken Tanaka wrote: > >> > >>> The most flexible scheme seems to have the parent take a > >>> configuration parameter that sets a default policy on interrupting > >>> the children when one child quits on Error. Then the child Stages > >>> could have an optional policy parameter to request different > >>> treatment than the parent's default shutdown policy. > >>> > >>> -Ken > >>> > >>> Kris Nuttycombe wrote: > >>> > >>>> Hi, all, > >>>> > >>>> I've got a exception handling policy question for all of you. > >>>> Here's the situation: > >>>> > >>>> In commons-pipeline, one or more child threads may be spawned to > >>>> control processing for a given stage. What should the error > >>>> handling policy be for Errors generated by the foreign method > >>>> calls? I catch all Exceptions, including RuntimeExceptions, and > >>>> record the faults in a monitor object that is visible at the > >>>> pipeline level. What I don't know is whether or not I should try to > >>>> catch Errors as well. The information in the Error object is > >>>> obviously potentially useful for debugging, but it's almost certain > >>>> that any Errors that occur can't be recovered from and ought to > >>>> abort processing of the whole pipeline. > >>>> > >>>> What should be the default behavior of a parent thread is when a > >>>> child thread dies due to an uncaught Error? Should the policy be to > >>>> immediately interrupt any sibling threads, or does this seem like > >>>> it would make it too easy to leave an external resource modified by > >>>> a Stage in an inconsistent state, and therefore sibling threads > >>>> should be asked to exit gracefully? Maybe the behavior on > >>>> interruption should be something that's set on a stage-by-stage basis? > >>>> > >>>> Thoughts, comments, suggestions? > >>>> > >>>> Kris > >>>> > >>> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > ===================================================== > Kris Nuttycombe > Associate Scientist > Geospatial Data Services Group > CIRES, National Geophysical Data Center/NOAA > (303) 497-6337 > [EMAIL PROTECTED] > ===================================================== > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > _________________________________________________________________ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
