Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43A2E199.9020904@day.com>
Date: Fri, 16 Dec 2005 16:47:37 +0100
From: Felix Meschberger <Felix.Meschberger@day.com>
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: jackrabbit-dev@incubator.apache.org
Subject: Re: Classloaders and extensions
References: <43A2CAB6.7080604@day.com> <43A2CEAC.9090709@apache.org>
In-Reply-To: <43A2CEAC.9090709@apache.org>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Stefano
>
> Maybe I'm missing something, but what is the advantage of this=20
> compared to, say, OSGi?=20
Hmm, how about an OSGi framework implementation, which uses the=20
repository ?? But until then, this is like a nice little useful thing.
> Why would I want to store my classes in a content repository=20
Well, it makes deployment far easier, than having to touch applications=20
and struggling with configuration files and class paths. It also takes=20
the notion "Everything is content" one step ahead. It is like storing=20
data and programs in the same location, the memory, isn't it ?
> and why would I want to have half of the wheels of existing component=20
> solutions reinvented?
Touch=E9 :-) But I think that (1) loading classes from a repository is a =

good thing to have - everything is content
>
> Please take these questions not as criticism, but as serious and=20
> honest curiosity.
You are welcome :-)

Regards
Felix