RE: LongRunning tasks

> BTW, it seems to me that this functionality might be added using a
> servlet filter.

I agree on this - I looked briefly at the filter interface, but lacked the
time to really experiment with it. So in the future, we should really look
at restructuring the LongRunning stuff this way if we could.

In general, I totally agree with your comments - as I look at the code
(which I wrote) I find myself saying "blech...this is really complicated."
BUT...I also suspect that if you try to implement it with filters you're
also going to find that its still pretty complicated. If anything, we might
well discover that we need multiple Barracuda filters for what is currently
handled in one class like ApplicationGateway:

  -(level 1) a filter to set up/tear down session stuff

  -(level 2) a LongRunning filter which intercepts LongRunning events and
processes them differently - sending a redirect page back to the client,
wrapping the second pass in a DeferredResponseWrapper, etc

  -(level 3) the ApplicationGateway filter, which does event dispatching

And what you end up with is three classes instead of one, plus required
changes to the web.xml. Part of the reason I ended up implementing it as I
did was that a) it was the easiest way to do it, and I was pressed for time,
and b) I wanted it to be available without any additional configuration
changes (ie. as easy as possible to use).

In terms of configuration, I agree with your comments about having one
central location for configging an app that uses Barracuda. For us, that is
not the web.xml, but rather our object-repository.xml. We do _most_
configuration here (and it should be noted that we could actually configure
the LongRunning event classes from here as well, although in the examples
given I am doing it through the events.xml file).

> >Of course, how best to implement it all remains to be seen, ...
>
> Agreed.   The feature is definitely cool and useful in the real world and
> it does give us a kick start at thinking about the possibilities for
> building other useful high level components.

Just to be clear, I'm totally open to redesign and improvement in this area.
I just don't have a lot of free cycles at this point. But we should use this
as a good case study for thinking about how we can clean things up in
general. If someone wants to take a stab at implementing it via servlet
filters, I'd love to see it...

> >We also need a good sample app that shows how to use all these things
> >and get people started quickly.
>
> This is probably the highest priority.  I hope this can get done
> soon.  Any volunteers?

I certainly intend to tackle this as soon as possible, but how soon that
will be is still unclear. We've learned a lot about how to leverage
Barracuda in the last year - in terms of project structure, UI features,
etc. I think others might really benefit from this, but I probably need a
couple of weeks of focused time to put it together, and that may not happen
for a bit. It would really, really be useful, however. I will see if I can
carve out some time in the next month or two to address this.

Christian
----------------------------------------------
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"


> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Jacob Kjome
> Sent: Tuesday, January 06, 2004 1:22 AM
> To: [email protected]
> Subject: RE: [Barracuda] LongRunning tasks
>
>
> Hi Christian,
>
> See comments below...
>
> At 10:49 AM 1/5/2004 -0500, you wrote:
> >Hey Jake,
> >
> >Good comments as usual.
> >
> > > So, we are officially not servlet 2.2 compatible anymore, eh
> (because of
> > > the new use of the servlet 2.3+ HttpServletRequestWrapper)?
> >
> >I _think_ we've actually been tied to 2.3+ for a bit now...the
> >HttpServletRequestWrapper stuff was already in there (with
> methods for 2.3
> >compliance), although I renamed the class.
>
> Well, in name it was.  Our HttpServletRequestWrapper implemented
> HttpServletRequest with extra methods to account for those in
> servlet 2.3,
> but I don't believe we were married to the 2.3 api there.  We
> also use some
> 2.3 features in various places in Barracuda, but only if servlet 2.3 is
> actually available.  Otherwise, we fall back to 2.2.  There are some
> servlet 2.3 specific features used in web.xml, but they aren't
> necessary to
> a working Barracuda and may simply be commented out for 2.2
> compatibility.  So, not until this move to using the
> javax.servlet.http.HttpServletRequestWrapper have we truly depended on
> servlet 2.3.  Again, I don't think this is bad, but I believe you
> have been
> one of the proponents of keeping 2.2 compatibility as long as we
> could get
> by with it.  That's why I was surprised by the change.
>
> At this point, most any app server worth its salt supports servlet
> 2.3.  Heck, Tomcat5 supports servlet 2.4.  I think we're safe.  Anyone
> still running Barracuda on Tomcat 3.x.xx?  I forget what
> Enhydra5.x.x uses
> as its Tomcat version internally?  Anyone know?  I know the goal was to
> move to a more recent version, but I'm not sure when the ETA for
> that was/is?
>
> > > Not sure I agree with the change in ApplicationGatway where
> HTML code is
> > > written out for the long running stuff.  First, that means that long
> > > running events are only supported for HTML clients such as
> web browsers
> > > and not other clients such as WAP phones and such.  Plus it doesn't
> > > seem right for the front controller to be writing markup to the client
> > > anyway.  That should be done in another layer, IMO.
> > >
> > > Also the fact that XMLC is being used by the core of Barracuda when
> > > Barracuda is supposed to be (relatively) agnostic on DOM
> > > implementations.  This means that if one wants to use, for
> > > instance, Jivan instead of XMLC, XMLC will still have to be
> available to
> > > account for Barracuda's internal use of XMLC.  Seems like this forces
> >library
> > > bloat on users.
> >
> >I agree with most of this in principle - it could certainly be
> better, more
> >pluggable, etc. But at this point, I simply don't have the time
> to go make
> >it do those things, so it will have to wait until someone wants
> to improve
> >it (patches welcome! ;-) The good thing is, the general logic
> should remain
> >pretty much the same regardless of where we are getting our DOM source.
>
> Ok, but that still doesn't address alternate client-types, since the code
> in Application Gateway is hardcoded to deal with only basic desktop HTML
> browsers only.
>
> > > Features like this ought to be able to be plugged in...Additions like
> >this,
> > > be they cool or not, make Barracuda inevitably more complex.
> Users should
> >be
> > > able to add features like this in if they want them and leave
> them out if
> > > they don't.
> >
> >Just to clarify - additions like this make the _Barracuda code_ more
> >complex; but they make _Barracuda as a framework_ much more powerful and
> >easy to use. And that's a big difference.
>
> I should have mentioned something about the overhead of added
> features that
> some people might not care to use.  The extra code is bound to slow
> Barracuda down, even if it is hardly noticeable.  Being able to plug
> something in allows one to decide whether to take the extra hit or
> not.  BTW, it seems to me that this functionality might be added using a
> servlet filter.  Well, not sure on that one since I haven't thought about
> it much, but servlet filters truly fit this pluggability issue.  They are
> there only if you configure it in web.xml and are completely absent from
> the runtime when not provided meaning you don't take any hit when
> you don't
> want to and there is no extra logic in the core code.  Seems like the
> perfect fit!
>
> >Per your email the other day about
> >"ease of use" (which I still mean to respond to) - one of the
> things we are
> >going to have to deal with is how to make Barracuda easier to use, and in
> >general, making the framework so users have to decide what to add in and
> >what to leave out is actually something that makes it harder to
> use, because
> >they have to understand how it works in order to understand how
> to configure
> >it. Indeed, I think part of Barracuda's steep learning curve
> comes from the
> >fact that we made it so configurable in the first place, even though the
> >majority of people aren't ever configurring it. This is part of
> the reason
> >why I implemented it the way I did - to make it as simple as possible for
> >people to use; they don't have to do any configuration of Barracuda -
> >everything's already there by default.
>
> Hmm...  I'm not sure that is the source of the steep learning curve.  I
> think it has more to do with lack of documentation on some of the core
> features.  Even I have to remind myself how things work
> sometimes.  I also
> think that a consistent centralized configuration scheme would
> help things
> here.  The use of Static variables can make things easy to configure for
> those who know all the different static variables to configure (with more
> being created all the time), but having something akin to XMLC's
> OutputOptions object or the like.  Something to wrap up all the
> configuration for the system.  A one stop shop for Barracuda
> configuration.  I haven't thought this through much, so take these ideas
> with a grain of salt, but I think the general idea makes sense.
>
> >Now, none of this is meant to negate your point: a) the code
> could certainly
> >be cleaner, b) it would probably be nice for it to be more
> pluggable, and c)
> >we really do need to think about these things for Barracuda 2.0. All I'm
> >trying to say is that we need to realize that configurability actually
> >_increases_ complexity. And so we want to make it possible to configure
> >stuff, but we also want to do more in the way of default
> implementation that
> >makes all the decisions for the user. That's the type of thing that will
> >make the framework easier to use.
>
> If you are talking about Struts-like configuration, I totally
> agree.  What
> a nightmare that can be.  However, as I've stated above, making things
> configurable doesn't mean things are necessarily made harder.  It
> just has
> to be done thoughtfully.  Somehow Picocontainer (
> http://www.picocontainer.org/ ) comes to mind as an interesting paradigm
> for this and other parts of Barracuda, but that's another topic
> for another
> day.
>
> >One final comment about Barracuda's "value proposition". I think the
> >perceived value of the framework, will not be so much in terms of the
> >component or event models, but rather the higher level
> "components" that we
> >build with it. For instance, what we've really done here is
> create a "Long
> >Running Component" (in a meta sense) - you can configure it,
> supply your own
> >template, etc. That's something that developers will go
> "wow...this saves me
> >_tons_ of time...I've _got_ to use this framework". In my opinion, that's
> >the type of reaction we need to be seeing in order to see
> Barracuda continue
> >to grow and prosper.
>
> >Along these lines, I think we need to consider creating
> components for like
> >Reports, Maint screens, dialogs, calendars, etc. All of these
> are components
> >in the high level, "meta" sense - they consist of templates, models for
> >populating those templates, some business logic, etc.
>
> Yes, but to continue to add more and more stuff like this on top of
> Barracuda's core infrastructure in the same way that the long
> running stuff
> was added would sooner than later bog down Barracuda and make the code
> rather coupled and unintelligible, not to mention forcing features that
> some might not care to use.  Don't get me wrong, I totally agree that we
> need these more high level components.  But just like taglibs,
> they should
> be features that users explicitly declare that they want to use.  This
> doesn't have to be done though excessive configuration.  It should be as
> simple as adding a JSP taglib to web.xml.  Let's not overstate the
> difficulty or learning curve of this task.  It shouldn't be that
> hard.  Keeping the core clean should be a high priority (one of the
> highest, IMO).
>
> >We also need a good
> >sample app that shows how to use all these things and get people started
> >quickly.
>
> This is probably the highest priority.  I hope this can get done
> soon.  Any
> volunteers?
>
> >  At any rate, all I'm saying here is that I think this is the type
> >of thing that is going to elicit "ah-ha" moments more than how
> pluggable we
> >make the internal implementation.
>
> Eclipse's pluggability is one of the biggest reasons for its
> popularity.  Ease of plugging new aha features in as if they were core
> services is pretty darn cool, if you ask me.  I think we could have the
> best of all worlds here:  a clean and blazing core with infinite
> pluggability of aha features.
>
> >Of course, how best to implement it all remains to be seen, but
> stuff like
> >this LongRunning stuff at least gives us a tangible example to start
> >thinking about...
>
> Agreed.   The feature is definitely cool and useful in the real world and
> it does give us a kick start at thinking about the possibilities for
> building other useful high level components.
>
> Jake
>
> >Christian
> >----------------------------------------------
> >Christian Cryder
> >Internet Architect, ATMReports.com
> >Project Chair, BarracudaMVC - http://barracudamvc.org
> >----------------------------------------------
> >"Coffee? I could quit anytime, just not today"
> >
> >
> > > -----Original Message-----
> > > From: [email protected]
> > > [mailto:[email protected]]On Behalf Of Jacob Kjome
> > > Sent: Monday, January 05, 2004 1:35 AM
> > > To: [email protected]
> > > Subject: Re: [Barracuda] LongRunning tasks
> > >
> > >
> > > Hi Christian,
> > >
> > > So, we are officially not servlet 2.2 compatible anymore, eh
> (because of
> > > the new use of the servlet 2.3+ HttpServletRequestWrapper)?  Fine
> > > by me as
> > > long as everyone else is ok with it.
> > >
> > > Not sure I agree with the change in ApplicationGatway where
> HTML code is
> > > written out for the long running stuff.  First, that means that long
> > > running events are only supported for HTML clients such as web
> > > browsers and
> > > not other clients such as WAP phones and such.  Plus it doesn't
> > > seem right
> > > for the front controller to be writing markup to the client
> anyway.  That
> > > should be done in another layer, IMO.
> > >
> > > Also the fact that XMLC is being used by the core of Barracuda when
> > > Barracuda is supposed to be (relatively) agnostic on DOM
> > > implementations.  This means that if one wants to use, for
> > > instance, Jivan
> > > instead of XMLC, XMLC will still have to be available to account for
> > > Barracuda's internal use of XMLC.  Seems like this forces library
> > > bloat on
> > > users.
> > >
> > > Anyway, the functionality seems pretty cool.  Seems like it could
> > > have been
> > > implemented slightly cleaner, though.  Features like this ought
> > > to be able
> > > to be plugged in.  I'm not saying I have the answer for how to do
> > > that, but
> > > I think we need to sit down and think about how to simplify
> the core of
> > > Barracuda.  Additions like this, be they cool or not, make Barracuda
> > > inevitably more complex.  Users should be able to add features
> > > like this in
> > > if they want them and leave them out if they don't.  Maybe a
> > > discussion for
> > > Barracuda 2.0?
> > >
> > > Jake
> > >
> > > At 06:20 PM 1/4/2004 -0500, you wrote:
> > > >I just checked a pretty massive change into cvs - this to
> add built in
> > > >support for Long Running tasks from with Barracuda. Check
> here for more
> > > >details:
http://barracudamvc.org/Barracuda/docs/events/long_running.html
> > >
> > >Comments and feedback welcome...
> > >
> > >Christian
> > >----------------------------------------------
> > >Christian Cryder
> > >Internet Architect, ATMReports.com
> > >Project Chair, BarracudaMVC - http://barracudamvc.org
> > >----------------------------------------------
> > >"Coffee? I could quit anytime, just not today"
> > >
> > >_______________________________________________
> > >Barracuda mailing list
> > >[email protected]
> > >http://barracudamvc.org/lists/listinfo/barracuda
> >
> > _______________________________________________
> > Barracuda mailing list
> > [email protected]
> > http://barracudamvc.org/lists/listinfo/barracuda
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://barracudamvc.org/lists/listinfo/barracuda

_______________________________________________
Barracuda mailing list
[email protected]
http://barracudamvc.org/lists/listinfo/barracuda