RE: Configuring Barracuda (specifying pluggable impl ementations)

Hi Guys,

> BTW, how does REQUEST_WRAPPER ever get set to a non-null value in
> ApplicationGateway?

The REQUEST_WRAPPER mechanism was added to support file uploading...
Basically... the subclasses need to override the 'wrap' method.
See calls to 'handleDefault' in ApplicationGateway.

I followed Diez's example and implemented file uploading using the Jakarta
Commons FileUpload Api.

Basically one just needs to 'set' the REQUEST_WRAPPER.
I used Diez's example and did this in the initializeLocal method.
See the installHttpRequestWrapper method.

  private void installHttpRequestWrapper() {
    File tempDir;
    tempDir =
(File)getServletConfig().getServletContext().getAttribute("javax.servlet.con
text.tempdir");
    REQUEST_WRAPPER = new FileUploadWrapper(tempDir.getAbsolutePath());
  }


  public static class FileUploadWrapper implements RequestWrapper {
    private String destinationDir;
    public FileUploadWrapper(String destinationDir) {
      this.destinationDir = destinationDir;
    }
    public HttpServletRequestWrapper wrap(HttpServletRequest
httpServletRequest) {
      return new HttpServletRequestWrapper(new
FileUploadMultipartRequest(destinationDir, httpServletRequest));
    }
  }


  public class FileUploadMultipartRequest extends HttpServletRequestWrapper
implements HttpServletRequest {
    private FileUpload fileUpload;
    private String destinationDir;
    private HttpServletRequest httpServletRequest;
    private List fileItems;
  
  
    public FileUploadMultipartRequest(String destinationDir,
HttpServletRequest httpServletRequest) {
      super(httpServletRequest);
      this.fileUpload = new FileUpload();
      this.destinationDir = destinationDir;
      this.httpServletRequest = httpServletRequest;
    }
  
    public FileUpload getFileUpload() {
      return fileUpload;
    }
  
    public void parseRequest() throws FileUploadException {
      this.fileItems = null;
  
      this.fileUpload.setRepositoryPath(this.destinationDir);
      this.fileUpload.setSizeMax(1000000);
  
      // maximum size that will be stored in memory
      this.fileUpload.setSizeThreshold(4096);
      this.fileItems =
this.fileUpload.parseRequest(this.httpServletRequest);
    }
  
    public List getFileItems() {
      return this.fileItems;
    }
  }

Regards
KD

Ps.
Diez's example uses the Oreilly Servlet Api to achieve the same.
See he's contrib package for the example.


-----Original Message-----
From: Christian Cryder [mailto:[email protected]]
Sent: 11 June 2003 07:26
To: [email protected]
Subject: RE: [Barracuda] Configuring Barracuda (specifying pluggable
implementations)


Hi Jake,

> 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?

Yeah, this was the idea. I just wanted to get feedback before I went and did
it on a broader scale. If you like it then we can start moving things over
as needed/desired.

> BTW, how does REQUEST_WRAPPER ever get set to a non-null value in
> ApplicationGateway?

Good question. This was something Diez added, and I'm not exactly sure how
he's using it. Diez? Care to explain?

> 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.

Yeah, these were originally put in here to give people hooks to plug in
different implementations. I think we should probably go ahead and eliminate
them because a) it will clean up the code quite a bit and b) I don't think
there are very many people actually plugging in custom implementations (like
I can only recall ever hearing of one or two folks who were actually doing
this). So the impact should actually be pretty minimal.

If I'm wrong on this, you folks who want to see these methods stay as they
are - please speak up!

> We also might want to address the issue of the event extension.

We should probably save that conversation for another email. I'm not opposed
to revisiting this, but it may be a bit before I can give it adequate
attention. I know we designed the event mechanism to support it, so its
definitely doable - I just can't recall the details (and people haven't
exactly been breaking down the doors requesting it, so its never been a huge
priority).

> The ObjectRepository scripting is very cool.

Per our conversation the other day, I do intend to try and write up
something on how to use this, but I'm not sure when I'll get to it. For now,
suffice it to say that in my opinion, object-repository.xml files are the
place where all Barracuda scripting should be happening (as opposed to the
application gateway assembler), so I'd just encourage folks to take a gander
at 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

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