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<[email protected]> 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
