Mailing-List: contact oscar-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oscar-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <433A6494.1070801@ungoverned.org>
Date: Wed, 28 Sep 2005 05:38:28 -0400
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720)
MIME-Version: 1.0
To: oscar-dev@incubator.apache.org
Subject: Re: Running Felix in a servlet engine
References: 
 <OF3AC3C197.588981A3-ON80257089.0037E221-80257089.003C0452@ca.ibm.com>
 <433A4BC1.8010203@ungoverned.org> <433A5796.1010105@odoko.co.uk>
In-Reply-To: <433A5796.1010105@odoko.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Upayavira wrote:

> But it sounds like you don't have a solution to the 'OSGi in a 
> servlet' problem, where the servlet container registers URLHandlers. 
> It is such a small issue in the greater scheme of things, but given 
> that Cocoon's entire user base is using Cocoon as a servlet right now, 
> we need to continue to offer Cocoon in that environment. Have you any 
> suggestions as to how we can move forward with this - ways we can ease 
> the problem? E.g. by banning Cocoon based OSGi apps from using the 
> URLHandler service? (which would be a shame, as we have a similar 
> notion, the SourceResolver, which would be nice to port over to 
> URLHandler). Or any other suggestions?


The issue we have is the fact that the stream and content factories are 
singletons, thus only one entity can be in control of them at a time. 
Period.

I am not saying that Felix should be this entity, but my current design 
makes Felix this entity since it makes sense coming from a Felix 
perspective.

One way or the other we have to create a single entity that sets itself 
as the appropriate factory and allows for extensibility by 3rd parties. 
This was the goal behind URL Handlers from the OSGi spec.

My current thinking just tries to extend URL Handlers so that it will 
also account for the fact that there may be multiple instances of the 
framework in memory at the same time.

Nothing prevents us from trying to create something that is more 
generic, where the assumption is that we just have multiple clients 
(some may be OSGi frameworks, some may be app servers, etc.). Of course, 
this may get much more complicated, too.

One thing is certain, though, is that we cannot come up with a solution 
that will work for legacy apps that assume that they are the ones to 
call the "set factory" method; code will have to be modified to use 
whatever solution we come up with.

I would still like to try to solve this issue for multiple instances of 
the OSGi framework before solving it in general; however, if everyone 
feels that we must come up with a general solution then we can try to 
discuss it.

-> richard