On 5/23/10 18:51, Morten wrote:
--- Den man 24/5/10 skrev Richard S. Hall<[email protected]>:
Fra: Richard S. Hall<[email protected]>
>
No, it doesn't. That's what I am saying, the spec doesn't
support it.
However, the Felix framework impl doesn't do anything to
prevent it.
Ok, I understand your point now.
Yes, that is what I am afraid of. It seems the OSGI
guys did not think about resources - only classes ? (So
require bundle does not in fact import everything - only the
classes).
That is not accurate. Resources inside of packages are
handled just
fine, only resources not in packages are not handled. It
would be
difficult to do otherwise, since there is no naming
convention for
resources outside of packages that would not result in
naming collisions
or split "packages" all over the place.
OK, but this requirement just means that it is extra hard to get non-OSGI jars
to work with OSGI as many, many libraries has extra resources in non-package
dirs.
Agreed. Unfortunately, it just not possible to port all legacy
mechanisms without changes, but luckily for most cases there are
workarounds.
Yes, I am also thinking about extender patteren. The
problem is that jruby uses many more non-class resources
that will also not work with classloader.getRessources. So
after registering, JRuby will fail later on when trying to
load its *.rb files etc.
Perhaps so. I'm not familiar enough with it to know.
Latest update: I got my final experimentation to work not by writing an
extender but by creating a bridge classloader between my bundle and the jruby
bundle which overloaded getResources to lookup using classloaders of both
bundles.
Works fine as far as I can tell but I have only tested it a few minutes -
hopefully it will continue to work with more complex examples.
Yeah, sounds reasonable.
P.S: I bought your book. Very informative! Thanks for writing it.
Excellent. Thanks for buying it. The final editing is well underway, so
hopefully you'll get your final version this Summer...finally! :-)
-> richard
/Cheers
Morten
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
