Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
From: Niclas Hedhman <niclas@hedhman.org>
Message-ID: <3156.202.146.68.8.1058955190.squirrel@www.hedhman.org>
Date: Wed, 23 Jul 2003 18:13:10 +0800 (MYT)
Subject: Re: Context Entries
To: <dev@avalon.apache.org>
In-Reply-To: <3F1D9DD2.5060201@apache.org>
References: <3F1D6BAD.1030504@apache.org>
        <3F1D8C88.4090103@apache.org>
        <3F1D9549.2060509@apache.org>
        <3F1D9DD2.5060201@apache.org>
Importance: Normal
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Stephen McConnell wrote:
> Berin Loritsch wrote:
>> With the *.home.dir and *.temp.dir, not all environments map well to
>> the way it is currently defined. The prime example is the *.home.dir
>> and the Servlet environment. With servlets, the resources are supposed
>> to be accessed via URL--because there is no guarantee that the
>> resource is not part of a packed WAR file. There is a workaround--but
>> it is not required for all servlet engines to allow for it (the
>> findRealPath method in the ServletContext). Other times it is just
>> simply the fact that the  container
>> is ultra-simple and does not offer access to the filesystem (which may
>> be a requirement for sandboxed components).
>
>
> I understand - but this is mixture of (a) a component declaring that it
> needs a working directory(e.g. James) and (b) the ability of a
> containment system to meet that contract. If a containment system cannot
>  provide a working directory then it has to "not-deploy" the component.
> I'm not saying that a containment system *must* provide a solution to
> the value, I am saying that if we are discussing home or temporary
> directories - then we use the same context keys across all containers.


Since I write a fair amount of J2ME apps, I have come to uise some tricks
to make the J2SE apps more J2ME port-friendly.
One of these issues revolves around the use of files and directories in
J2SE which my J2ME environment doesn't support.
I use an interface expressing the need, a wrapper implementation for each
of the two main environments and a "storage" class supplied by the J2ME
vendor for the J2ME environment (and standard File, FileXXStream in J2SE).

I think this approach is suitable for this case as well;

public interface WritableStorage extends ReadableStorage
{
    OutputStream openForWrite( String name ) throws IOException;
    OutputStream openForAppend( String name ) throws IOException;
}

And if the "urn:avalong:home.dir" returns a WritableStorage object
instead, the container has a lot of options on how to support (or not)
that, such as sandboxing, specialized storage (possibly remote), and so
on.


Adding my 0.02 ringgit to a very academic discussion, that is not easy to
follow, but sure the end result will be good.


Niclas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org