Certainly these sorts of ideas make sense, but you don't necessarily
need special support from the framework. You can always create some sort
of "installer" service that reads in a JAR file, makes modifications to
it, then installs the modified JAR file into the framework. Then just
always using this "installer" service instead of installing JARs
directly into the framework.
I understand that you said you don't want a pre-processing step, but I
assume you meant external to the framework. An "installer" approach is
largely equivalent to have special support built into the framework and
has the benefit that it works across all framework implementations.
-> richard
Fredrik Alströmer wrote:
Hi People,
I've been having this idea, and I was trying it out a little (using
equinox) but it didn't work very well (not at all actually), and I
thought before I try too much, I'll ask the experts, if this is even
viewed as acceptable behavior.
Here's the thing, I'm trying to intercept bundles before they're
evaluated by the framework (imagine if you will a synchronous
'installing' event, which I couldn't find anywhere). For example, I'd
like to inspect the contents of the bundle, and 'manipulate' it
without actually having to do so as a preprocessing step. As a
hypothetical example, let's say we want to define an import-package,
and then defining a bundle-activator, using a class from the specified
import-package. I realize there are serious security concerns here, so
I'm just trying to get a feel for it.
What I'm getting at is, using archives that are built for other
frameworks, or other situations, and tweaking them at runtime to
appear as OSGi bundles, without actually having to modify the archive.
Does that seem possible at all?
Greetings,
Fredrik.
------------------------------------------------------------------------
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
