On May 27, 2008, at 21:10 , Kass, Samuel-P58051 wrote:
And if I want to use an OSGi activator for initialization, I'll
need to run on
a system that calls the start() method of my activators.
For this I would have the activator simply instantiate the
POJO and throw away the whole activator if you don't use
OSGi. Then of course you need a system to instantiate all
your POJO's, that's right, so you might end up mimicking some
mechanisms of the OSGi framework.
That sounds a little annoying but reasonable :)... I think the thing
that would be the hardest to "fake" here is the Bundle/BundleContext
that might be used by activator code.
In general, when running in some kind of container, there is some kind
of interface from the component to the container. Obviously for OSGi
this is the BundleContext. You mainly use it to register and lookup
services. This context should only be used in the activator, and if
you don't run your POJO in OSGi, you should loose the activator
completely.
That means that if you have a POJO that depends on some other
services, you need some way to externally "inject" them. That would
again be code you'd have to write yourself when outside of OSGi but it
could be as simple as using invoking a setter on your POJO. You might
need to build a very simple service registry yourself (maybe as simple
as a Map<String, Object> if you don't need services with the same name
but different properties and complex filtering that OSGi supports).
Any other areas where the typical application becomes dependent on
OSGi
code and would have to be refactored out? Resource loading comes to
mind...
As long as you package your resources in your JAR and load them from
it, there should not be any difference between OSGi and non-OSGi usage
there. I might be forgetting something too, but I think we've already
covered the most common things that might need to be done.
Sure, that is an interesting question. Probably some features
will be harder to replicate than others, especially given the
constraint that you basically run in an applet sandbox (those
features would be dynamic updating of code, isolating modules
from each other, and resolving package dependencies,
especially if you need to be able to use different versions
of the same package simultaneously). However, for simpler
applications, those features might not be needed at all, and
using OSGi as a way to develop reusable components is still
something worthwhile (in my opinion).
I agree... And since we're already in that world today, we already
have
had to deconflict all our dependencies to use the same version. While
I'd like to lift that restriction for application code, I can suggest
that rule be maintained for the core engine so it could be used in
this
fashion.
If you really need two different versions of the same class or
package, you can always use byte code manipulation (after compilation)
to simply "rename" these two identical packages to have different
names and manipulate the code that uses these packages in the same
way. That way your sourcecode does not need to be changed and this
step can only be done when not using OSGi. However, I would not
recommend doing that unless you really need to. :)
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
