RE: Configuring Barracuda (specifying pluggable implementations)

One other comment on this subject...

I said that I thought all major packages should use this approach, but I'm
not sure to what extent the other packages will need pluggability at this
particular point. In other words, some packages (like the event pkg) are
probably _more_ suited for immediate conversion to this approach, but ALL
packages should use this approach when they need it.

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: Wednesday, June 11, 2003 10:37 AM
> To: [email protected]
> Subject: Re: [Barracuda] Configuring Barracuda (specifying pluggable
> implementations)
>
>
> Hi Christian,
>
> This all sounds like a very good idea.  I like how it all works very much!
>
> Do we want to do all this for DefaultEventContext as well?
> Actually, any direct reference to a "Default" implementation
> ought to be able to be scripted via the ObjectRepository along
> with the A_Classes technique.  Are we going to have an A_Classes
> for each major package?
>
> BTW, how does REQUEST_WRAPPER ever get set to a non-null value in
> ApplicationGateway?
>
>
> Note that I updated plankton/Classes.java to use
> Class.forName(String, boolean, ClassLoader) which is the same as
> the old method, but looks a bit cleaner.  I also cleaned up some
> unused code and comments in the ApplicationGateway.  Shouldn't
> have changed behavior.
>
> Oh, and in ApplicationGateway you commented out
> getNewEventPoolInstance().  I am definitely ok with that, but I
> hope everyone is.  Does this affect anyone who was extending
> ApplicationGateway?  Probably not, but I thought I'd ask.
>
> We also might want to address the issue of the event extension.
> I know we discussed this before, but I don't think we ever came
> up with a final answer on making this transparent and I've
> forgotten all the issues involved.  It seems it is pretty
> hardcoded to ".event".  I wonder if we couldn't figure out how to
> let the <servlet-mapping> in web.xml just define this for us and
> not worry about it later.  Again, I haven't thought this through
> so I'm probably washing over a number of issues involved.
>
>
> The ObjectRepository scripting is very cool.  Thanks for doing
> this.  I think it will really benefit everyone and we can also
> make the claim that Barracuda is totally pluggable after we apply
> these types of changes to all existing references to "Default"
> implementations.
>
> later,
>
> Jake
>
>
> At 10:42 PM 6/9/2003 -0600, you wrote:
>
> Hi folks,
>
> Jake and I have been having some conversations on how to make it
> easier for
> developers to specify alternate implementations of interfaces within
> Barracuda.
>
> The core.event package is one of the more common places where developers
> might need to do this, and right now its pretty cumbersome...you have to
> extend ApplicationGateway and override provider methods. Blech.
>
> I've been thinking there's got to be an easier way, and so I
> spent some time
> tonight working on a sample implementation fpr your review. Here are the
> details (from what I just checked into cvs)...
>
> ------------------------------
> <b>csc_060903.3</b> - Preliminary work for Jake's review on a new way to
> configure
> pluggable classes. Basically, I modified
> org.enhydra.barracuda.plankton.Classes to offer
> a couple of new methods for getting a Class or an instance of a
> Class (using
> some simple
> caching for efficiency sake). Then I created a new
> org.enhydra.barracuda.core.event.A_Classes.
> This class defines constants that refer to default class
> names...they can be
> overridden
> via the Object Repository scripting approach. The basic idea here is that
> when a class needs
> to instantiate something that implements the interface, it uses
> Classes.newInstance(String clName),
> where clName is the value defined in A_Classes. I have currently
> implemented
> this in
> ApplicationGateway, for both DefaultEventGateway and
> DefaultEventPool. This
> is to provide
> an example of the approach I have in mind. Jake and others...your comments
> and feedback would
> be appreciated.
> ------------------------------
>
> Basically, what this means is that when you want to provide a different
> implementation of a class, all you have to do is something like
> this in your
> object-repository.xml:
>
>     <object class="org.enhydra.barracuda.core.event.A_Classes">
>       <prop name="DEFAULT_EVENT_POOL">foo.blah.MyCustomEventPool</prop>
>     </object>
>
> This is essentially overriding the class name that will be used for event
> pooling. It could also be used for configuring the classes in question,
> again via statics. For instance, if I wanted to configure
> MyCustomEventPool,
> I could add another section in my object repository just like this:
>
>     <object class="foo.blah.MyCustomEventPool">
>       <prop name="RUN_REALLY_FAST">true</prop>
>     </object>
>
> At any rate, I'd encourage those of you who are interested, to take a peak
> at the latest version of ApplicationGateway and let me know what
> you think.
> Your comments and feedback would be very 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