Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: local policy)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Date: Sun, 10 Oct 2010 03:34:08 +0530
From: Sanjeeb Sahoo <Sahoo@Sun.COM>
Subject: Re: [DISCUSS] Containerisms
In-reply-to: <4CB0694B.8060608@gmail.com>
Sender: Sanjeeb.Sahoo@Sun.COM
To: dev@felix.apache.org
Cc: Felix Meschberger <fmeschbe@gmail.com>
Reply-to: Sahoo@Sun.COM
Message-id: <4CB0E6D8.9060907@Sun.COM>
References: <AANLkTim+kBVoAHaUxa6xE9N9r7vCgndgx3CV0Ddqy5S2@mail.gmail.com>
 <4CAF4A3F.4050406@gmail.com>
 <AANLkTi=PavvPS0GDfTwdrr_HStLBCW1KwZ1iOfpWDfd_@mail.gmail.com>
 <4CB0694B.8060608@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423
 Thunderbird/3.0.4

On Saturday 09 October 2010 06:38 PM, Felix Meschberger wrote:
> Hi,
>
> On 08.10.2010 20:08, Guillaume Nodet wrote:
>    
>> On Fri, Oct 8, 2010 at 18:43, Felix Meschberger<fmeschbe@gmail.com>  wrote:
>>
>>      
>>> Hi,
>>>
>>> First of all: I agree with Richard in that we should at all cost prevent
>>> containerisms.
>>>
>>> Second: I do not really understand what the problem is, that must be
>>> solved with this containerism and which cannot be solved with regular
>>> OSGi API.
>>>
>>>        
>> The real problem is to be able to discover resources in the bundle class
>> space. For example, i want to know all resources in foo/bar/**/*.xml The
>> OSGi API does not provide any way to do that atm and a lot of libraries use
>>   some custom things based on jars / file urls to actually iterate and
>> discover those resources.
>>      
> I wonder how you would be able scan the class space by pure ClassLoader
> API, unless you check for the class loader being an URLClassLoader and
> access the configured URLs....
>
> But then: How about the Bundle.findeEntries ?
>
>    
I tend to agree that with some knowledge of how OSGi treats 
Bundle-ClassPath entries, one can implement scanning using Bundle APIs 
like the one pointed out by Felix and the code should run fine all 
frameworks.
>> The problem is just about a way to actually do things.  It seems in the
>> enterprise world (JEE, middleware),  we're more keen on bending the purity a
>> bit to the benfit of being able to achieve our goals and we're also more
>> keen on doing that for third party libraries.
>>      
> Yeah, and I would be so undiplomatic to say, that this is at the heart
> of today's J2EE mess ....
>
> IMHO you can bend the purity once, but you then will bend it twice,
> three times, etc. Until end up in a complete mess ...
>
> My intepretation is that the J2EE world has realized this stituation,
> starts embracing OSGi and along the lines of "getting stuff done by
> bending purity if required" now starts and tries to do the same to the
> OSGi specs. I am not really happy with this development ....
>
> But this is diverting this discussion ...
>
>    

I don't think Java EE specs are that bad that OSGi frameworks have to 
provide all sorts of nasty features to support Java EE APIs in an OSGi 
environment. I can't recall using any Felix feature to implement OSGi/EE 
specs in GlassFish project [1].

Thanks,
Sahoo