getResourceAsStream() is an instance method of java.lang.Class, so as long
as you stick with that, you're not tied to any particular deployment
environment.
Ian
Ian D. Stewart
Open Systems Engineer II
Enterprise Midrange - Bank One Infrastructure & Operations
[EMAIL PROTECTED]
(614) 213-6100
"Andrew Hill" <[EMAIL PROTECTED]> on 07/30/2003 10:49:19 PM
Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:
Subject: RE: [OT] Best super-class for context handling.
<snip>
InputStream is =
servlet.getServletContext().getResourceAsStream("/WEB-INF/dir/file.x");
</snip>
Thats fine if your in an action, but down in your business classes you dont
want to be dependant on the servlet api classes.
Obviously the trick is to have some kind of interface (which in my apps I
usually name "IStreamSource") that will provide a stream when passed some
kind of url (or even more abstract key mapped to a url internally) and will
allow the other classes to be independent of whatever environment they are
in (as one would have different implementations for different environments)
when it comes to reading files. (The servlet version would simply wrap a
call to getResourceAsStream on its reference to the servlet context)
One thing Im not sure about is whether it is ok to hang onto a reference to
the servlet context in this streamsource object (so that it can be shared
between requests and not have to be passed in method parameters all over
the
place). I dont think that would work too well in a distributed environment
right? So we need to provide a new streamsource instance for each request
and pass it to any class that needs it or that might feel like calling some
other class that might need it (ad infinitum)... (?)
It would be nicer for the classes that need an IStreamSource instance to be
able to get them from somewhere themselves, but how to achieve this without
exposing the servlet api stuff to them?
What is the best practice here?
-----Original Message-----
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
Sent: Thursday, 31 July 2003 00:34
To: Struts Users Mailing List
Subject: Re: [OT] Best super-class for context handling.
On Wed, 30 Jul 2003, Simon Kelly wrote:
> Date: Wed, 30 Jul 2003 15:47:55 +0200
> From: Simon Kelly <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: [OT] Best super-class for context handling.
>
> Ah, right.
>
> Not sure whether that's what I'm after.
>
> Here's a better explination.
>
> I am using files that are contained within the /WEB-INF/ dir within the
web
> application to hold information required by the business logic. These
files
> are not part of the controller or view but are required to generate the
> content data for the action classes. So I need something that will get
the
> paths regardless of the enviroment they are in. I have chosen to pass all
> file names within the business logic in the form /WEB-INF/dir/file.x and
> have been using context.getRealPath() [or the correct method if that's
> wrong] to get the path name (which I had thought would be ok as it will
> always return the correct path regardless of where the webapp is
deployed).
>
> Is this wrong, and is there a better way to do it?
>
Assuming you're in an Action, do this:
InputStream is =
servlet.getServletContext().getResourceAsStream("/WEB-INF/dir/file.x");
It will be portable everywhere, even if you end up running on containers
that don't expand your webapp into an unpacked directory -- in those
environments, getRealPath() will return null.
> Cheers
>
> Simon
>
Craig
---------------------------------------------------------------------
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]
This transmission may contain information that is privileged, confidential and/or
exempt from disclosure under applicable law. If you are not the intended recipient,
you are hereby notified that any disclosure, copying, distribution, or use of the
information contained herein (including any reliance thereon) is STRICTLY PROHIBITED.
If you received this transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard copy format. Thank
you.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
