felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjeeb Sahoo <Sa...@Sun.COM>
Subject Re: [DISCUSS] Containerisms
Date Sat, 09 Oct 2010 22:04:08 GMT
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 
>> 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].


View raw message