I won't claim to totally understand your scenario, but if your bundles
are using external packages, then the bundle must import them.
Also, it is worthwhile to understand the distinction between the two
configuration properties for dealing with class path packages:
org.osgi.framework.system.packages - this lists packages from the class
path that the system bundle should export so that bundles can import
them.
org.osgi.framework.bootdelegation - this lists packages from the class
path that bundles will automatically be given access to whether they
import them or not.
If your bundle explicitly imports the packages, then you must include
class path packages on the system packages property, even if you boot
delegate them otherwise the bundle will not be able to resolve.
However, if you boot delegate a package then the bundle doesn't need to
import the package at all, but this is not the preferred way of doing
things since it makes the dependency invisible...of course if you don't
plan on using the bundle separately or on any other framework, then
maybe it doesn't matter.
So needless to say, if your bundle explicitly imports packages that are
in the EAR and not exported by other bundles, then you must somehow
expose to them the stuff in the EAR that they need. This is what you
are doing with the system packages property, you are telling the System
Bundle to offer to export it.
When the System Bundle gets a request for that package it will do
something like:
this.getClass().getClassLoader().loadClass(name);
Which will delegate the class load request to the class loader that
loaded the Felix classes, which in your case I guess would be the class
loader responsible for loading stuff from the EAR. Thus everything
appears to be wired up correctly.
So, I am not really sure what part you do not like. I think the issue
you are seeing is that OSGi modularity forces you to be precise about
dependencies, which ultimately is a good thing. If you don't want to be
precise, then you should use boot delegation for packages you don't
want to import and then remove these packages from the bundle's
imported packages...but this would not be my recommended approach.
-> richard
On Jun 21, 2007, at 4:57 PM, Todd Nist wrote:
Hi,
I am attempting to embed Felix in both JBoss and OC4J and while I am
able to get it to work, I am a little confused as to why and I
certainly
do not like my current solution.
public class FelixOSGiProvider extends OSGiProvider {
/**
* Default Constructor.
*/
protected FelixOSGiProvider(){}
/**
* Method to start the underlying OSGi runtime.
* @throws Exception for startup exceptions.
*/
public void start() throws Exception {
System.out.println("---Starting up Felix OSGi Container
18---");
// Create a case-insensitive configuration property map.
Map configMap = new StringMap(false);
// Configure the Felix instance to be embedded.
configMap.put(FelixConstants.EMBEDDED_EXECUTION_PROP,
"true");
configMap.put(FelixConstants.SERVICE_URLHANDLERS_PROP,
"false");
// Add the host provided service interface package and the
core OSGi
// packages to be exported from the class path via the
system bundle.
configMap.put(Constants.FRAMEWORK_SYSTEMPACKAGES,
"org.osgi.framework; version=1.3.0,"
+ "org.osgi.service.packageadmin;
version=1.2.0,"
+ "org.osgi.service.startlevel; version=1.0.0,"
+ "org.osgi.service.url; version=1.0.0,"
+ "com.leica.osgi.services; version=1.0.0,"
+ "com.leica.osgi.entity; version=1.0.0");
configMap.put(FelixConstants.AUTO_START_PROP +
".1","file:///C:\\workspace\\Leica-OSGi-ServiceImpl-
Bundle\\build\\com.l
eica.osgi.serviceImpl.jar ");
configMap.put(BundleCache.CACHE_PROFILE_DIR_PROP,
"c:\\OSGiBundles\\Leica-OSGi-Bundles");
//Put the default Activator,
List<BundleActivator> baseBundles = new ArrayList
<BundleActivator>();
baseBundles.add(this.getActivator());
// Now create an instance of the framework.
Felix felix = new Felix();
felix.start(new MutablePropertyResolverImpl(configMap),
baseBundles);
}
}
I have an EAR that contains the following .jars:
com.leica.osgi.services.jar (Contains the ServiceAPI - interfaces)
com.leica.osgi.entity.jar (Contains Entities)
framework.jar (contains class to bootstrap felix)
leica.war (contains a Servlet that creates an instance of the Felix
framework by using classes in framework.jar)
The only way I could get this to work was to include the
"com.leica.osgi.services" and "com.leica.osgi.entity" packages in the
FRAMEWORK_SYSTEMPACKAGES property. The bundle loaded by felix below,
com.leica.osgi.serviceImpl.jar, provides an implementation of a simple
OSGi Bundle that provides a simple service to getAllUsers().
When the application is deployed, the embedded Felix instance is
created
by the StartupServlet which binds the BaseBundleActivator to the JNDI
tree. When an EJB is called that is dependent on an OSGi service, it
looks up the BaseBundleActivator from the JNDI tree and invokes the
appropriate method; in this case, getAllUsers().
The OSGi service, is dependent on importing packages from
com.leica.osgi.services and com.leica.osgi.entity, which are located in
the .ear file. This has me a bit confused, since these packages are
deployed by the .ear how am I finding the classes in my Service?
Should
I not get a ClassNotFoundException or some other error?
I really to not want to have to include all the packages of the system
as part of the FRAMEWORK_SYSTEMPACKAGES. Ideally, I would prefer that
the entities, serviceAPI and ServiceImpl are all bundles and deployed
inside the embedded Felix instance and allow the EJB's to access them
similar to the above.
So I guess my first question is why does this work?
Is it possible to remove the additional packages form the
FRAMEWORK_SYSTEMPACKAGES and still gain access to them from within the
EJB container? Do I need a custom class loader to support this?
Is this even possible?
I tried adding the com.leica.* to the FRAMEWORK_BOOTDELEGATION packages
and removed the reference to them from the FRAMEWORK_SYSTEMPACKAGES,
but
then I got an error that the bundle could not find a required import,
com.leica.osgi.entity.
Thanks is advance for your assistance.
Regards,
Todd
