September 2009 - jboss-osgi-dev - Jboss List Archives

[JBoss OSGi Development] - Re: Cannot resolve circular dependencies

by thomas.diesler＠jboss.com

I isolated the issue sufficiently to this problem BundleC exports A, B imports A BundleD exports A, imports A, B Both bundles will only resolve if one uses a self dependency. I modified the code such that the Domain warns if a requirement resolves against multiple modules | Module firstMatch = null; | for (Module other : modules) | { | List<Capability> capabilities = other.getCapabilities(); | if (capabilities != null) | { | for (Capability capability : capabilities) | { | if (capability.resolves(other, module, requirement)) | { | if (firstMatch != null) | { | String otherName = other.getName() + ":" + other.getVersion(); | String firstName = firstMatch.getName() + ":" + firstMatch.getVersion(); | log.warn("Requirement " + requirement + " resolves agaist " + firstName + " and " + otherName + " - using first."); | } | if (firstMatch == null) | firstMatch = other; | } | } | } | } | and | I extended the interface like this | | public interface Capability extends Serializable | { | /** | * Whether this capability resolves the requirement | * | * @param capModule the capability module | * @param reqModule the requirement module | * @param requirement the requirement | * @throws IllegalArgumentException for a null requirement | * @return true when it is resolves the requirement | */ | boolean resolves(Module capModule, Module reqModule, Requirement requirement); | } | | which allows capability/requirement matching in the context of both modules. | | | | public interface Capability extends Serializable | | { | | /** | | * Whether this capability resolves the requirement | | * | | * @param capModule the capability module | | * @param reqModule the requirement module | | * @param requirement the requirement | | * @throws IllegalArgumentException for a null requirement | | * @return true when it is resolves the requirement | | */ | | boolean resolves(Module capModule, Module reqModule, Requirement requirement); | | } | | | | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254146#4254146 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254146

14 years, 7 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Autostart bundles when deployed in JBossAS

by thomas.diesler＠jboss.com

Here is an update to the issue I removed the LifecycleCallbackItem and its associated Thread Instead I use a wrapper around the Deployers that are associated with the MainDeployer http://anonsvn.jboss.org/repos/jbossas/projects/jboss-osgi/projects/runti... This still relies on implementation detail and I'd like to replace the wrapper with some kind of listener that I can associate with the MainDeployer. | public OSGiDeployersWrapper(MainDeployer mainDeployer, OSGiBundleManager bundleManager) | { | if (bundleManager == null) | throw new IllegalArgumentException("Null bundleManager"); | if (mainDeployer instanceof MainDeployerImpl == false) | throw new IllegalStateException("Cannot instrument: " + mainDeployer); | | this.mainDeployer = mainDeployer; | this.bundleManager = bundleManager; | | // Swap the deployers implementation | MainDeployerImpl mainDeployerImpl = (MainDeployerImpl)mainDeployer; | this.deployers = mainDeployerImpl.getDeployers(); | mainDeployerImpl.setDeployers(this); | } | | public void process(List<DeploymentContext> deploy, List<DeploymentContext> undeploy) | { | // Delegate to the original deployers | deployers.process(deploy, undeploy); | | // OSGi bundles resolve phase | afterDeployersProcess(deploy, undeploy); | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4253629#4253629 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4253629

14 years, 7 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Autostart bundles when deployed in JBossAS

by thomas.diesler＠jboss.com

To reproduce #1 Build the installer mvn -Pdistro clean install #2 Install MC Framework in jboss-5.2.0 minimal #3 Delete default bundles rm -rf server/minimal/deploy/osgi #4 Start the server | 12:12:55,287 INFO [OSGiBundleManager] JBossOSGi Runtime - Microcontainer | 12:12:55,288 INFO [OSGiBundleManager] 1.0.2-SNAPSHOT | 12:12:55,293 INFO [FrameworkEventsPluginImpl] Bundle STARTING: Bundle{system.bundle:0.0.0} | 12:12:55,335 INFO [FrameworkEventsPluginImpl] Service REGISTERED: Service{id=1 bundle=system.bundle:0.0.0 classes=[org.jboss.osgi.spi.service.MicrocontainerService]} | 12:12:55,400 INFO [FrameworkEventsPluginImpl] Service REGISTERED: Service{id=2 bundle=system.bundle:0.0.0 classes=[org.osgi.service.packageadmin.PackageAdmin]} | 12:12:55,404 INFO [FrameworkEventsPluginImpl] Service REGISTERED: Service{id=3 bundle=system.bundle:0.0.0 classes=[org.osgi.service.startlevel.StartLevel]} | 12:12:55,407 INFO [FrameworkEventsPluginImpl] Bundle STARTED: Bundle{system.bundle:0.0.0} | 12:12:55,409 INFO [FrameworkEventsPluginImpl] Framwork STARTED | 12:12:55,664 INFO [ProfileServiceBootstrap] Loading profile: ProfileKey@3c4c33[domain=default, server=default, name=minimal] | 12:12:55,666 INFO [AbstractServer] Started: JBoss Server[5.2.0.Beta1 (build: SVNTag=JBoss_5_2_0_Beta1 date=200909022330)] in 14s:470ms | #5 Deploy Bundle jbosgi142-bundleA.jar | 12:16:15,779 INFO [FrameworkEventsPluginImpl] Bundle INSTALLED: Bundle{jbosgi142-bundleA:0.0.0} | 12:16:15,938 INFO [OSGiBundleResolverDeployer] Unresolved: Bundle{jbosgi142-bundleA:0.0.0} | #6 Deploy Bundle jbosgi142-bundleX.jar | 12:16:50,849 INFO [FrameworkEventsPluginImpl] Bundle INSTALLED: Bundle{jbosgi142-bundleX:0.0.0} | 12:16:50,968 INFO [FrameworkEventsPluginImpl] Bundle RESOLVED: Bundle{jbosgi142-bundleX:0.0.0} | 12:16:50,973 INFO [FrameworkEventsPluginImpl] Bundle RESOLVED: Bundle{jbosgi142-bundleA:0.0.0} | 12:16:50,975 INFO [FrameworkEventsPluginImpl] Bundle STARTING: Bundle{jbosgi142-bundleX:0.0.0} | 12:16:50,975 INFO [FrameworkEventsPluginImpl] Bundle STARTED: Bundle{jbosgi142-bundleX:0.0.0} | 12:16:50,977 INFO [FrameworkEventsPluginImpl] Bundle STARTING: Bundle{jbosgi142-bundleA:0.0.0} | 12:16:50,988 INFO [FrameworkEventsPluginImpl] Bundle STARTED: Bundle{jbosgi142-bundleA:0.0.0} | This shows the behaviour with the LifecycleCallbackItem approach. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4253533#4253533 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4253533

14 years, 7 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Autostart bundles when deployed in JBossAS

by thomas.diesler＠jboss.com

There is an approach from Ales, which introduces a new state 'Reset' and resets the context to Described when it cannot get resolved. http://anonsvn.jboss.org/repos/jbossas/projects/demos/microcontainer/trun... This approach fails however for bundles with self dependencies. I also have made an attempt which involves a LifecycleCallbackItem and uses the PackageAdmin in a seperate Thread to resolve and progress bundles http://anonsvn.jboss.org/repos/jbossas/projects/jboss-osgi/projects/runti... | public void deploy(DeploymentUnit unit, OSGiBundleState bundleState) throws DeploymentException | { | bundleState.getBundleManager(); | | ControllerContext context = unit.getAttachment(ControllerContext.class); | DependencyInfo di = context.getDependencyInfo(); | | LifecycleCallbackItem lifecycleCallbackItem = new LifecycleCallback(unit); | di.addLifecycleCallback(lifecycleCallbackItem); | } | | private class LifecycleCallback implements LifecycleCallbackItem | { | private DeploymentUnit unit; | private PackageAdmin packageAdmin; | private DeployerClient deployerClient; | | public LifecycleCallback(DeploymentUnit unit) | { | this.unit = unit; | | OSGiBundleState bundleState = unit.getAttachment(OSGiBundleState.class); | BundleContext sysContext = bundleState.getBundleManager().getSystemContext(); | ServiceReference sref = sysContext.getServiceReference(PackageAdmin.class.getName()); | packageAdmin = (PackageAdmin)sysContext.getService(sref); | | deployerClient = unit.getAttachment(MainDeployer.class); | } | | public void uninstall(ControllerContext ctx) | { | OSGiBundleState bundleState = unit.getAttachment(OSGiBundleState.class); | unresolvedBundles.remove(bundleState); | } | | public void install(ControllerContext ctx) throws Exception | { | Runnable runnable = new Runnable() | { | public void run() | { | try | { | // [TODO] remove this hack and find a way to trigger | // PackageAdmin after the context has been deployed | Thread.sleep(100); | } | catch (InterruptedException e) | { | // ignore | } | | OSGiBundleState bundleState = unit.getAttachment(OSGiBundleState.class); | | // Add the new bundle to the list of unresolved | unresolvedBundles.add(0, bundleState); | OSGiBundleState[] unresolved = new OSGiBundleState[unresolvedBundles.size()]; | unresolvedBundles.toArray(unresolved); | | // Try to resolve all unresolved bundles | packageAdmin.resolveBundles(unresolved); | if (bundleState.getState() != Bundle.RESOLVED) | log.info("Unresolved: " + bundleState); | | for (OSGiBundleState aux : unresolved) | { | if (aux.getState() == Bundle.RESOLVED) | { | unresolvedBundles.remove(aux); | | try | { | // When resolved progress to INSTALLED | String name = aux.getDeploymentUnit().getName(); | deployerClient.change(name, DeploymentStages.INSTALLED); | } | catch (DeploymentException ex) | { | log.error(ex); | } | } | } | } | }; | new Thread(runnable).start(); | } | | public ControllerState getWhenRequired() | { | return new ControllerState(getStage().getName()); | } | | public ControllerState getDependentState() | { | return null; | } | | public Object getBean() | { | return null; | } | } | The separate Thread was necessary because the context is still installing when the PackageAdmin tries to progress to stage CLASSLOADER. Conceptually, there are two passes needed for bundle deployment. Phase #1: Install bundles (reqstage == DESCRIBE ) Phase #2: Resolve & Start bundles (reqstage == INSTALLED) Perhaps a callback for when the Phase #1 is needed or is there any other way to get rid of that Thread that starts Phase #2? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4253529#4253529 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4253529

14 years, 7 months

1
0
0 / 0

[JBoss OSGi Development] - Autostart bundles when deployed in JBossAS

by thomas.diesler＠jboss.com

The basic issue is that a bundle deployment when put in requiredStage = DeploymentStages.DESCRIBE it will only progress to Bundle.INSTALLED, hence the bundle with not get RESOLVED nor STARTED. When requiredStage = DeploymentStages.CLASSLOADER or above, the bundle can start when all its dependencies are resolved. The bundle deployment will however fail, if it has unresolved dependencies. The desired behaviour is: Bundles with unresolved dependencies get INSTALLED without error. Bundles with resolved dependencies get STARTED without error. A bundle that could only get INSTALLED (but not RESOLVED) gets STARTED when it's dependencies can be RESOLVED. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4253522#4253522 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4253522

14 years, 7 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Cannot resolve dependency against unstarted bundle

by alesj

"alesj" wrote : | But what's the issue? | Should it be resolved against deployments that are past CLASSLOADER? | "thomas.diesler(a)jboss.com" wrote : | we need to somehow resolve PackageRequirements against context's in state CLASSLOADER. | Yeah, I don't see why we need fully installed deployment to resolve against. I assumed there is some reason to it, hence hacked around it. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252880#4252880 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252880

14 years, 8 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Cannot resolve dependency against unstarted bundle

by alesj

"thomas.diesler(a)jboss.com" wrote : | So it seems that RequirementDependencyItems can only resolve againt INSTALLED contexts. | Yes. But what's the issue? Should it be resolved against deployments that are past CLASSLOADING? In my demos, to automagically pick up DESCRIBED deployments, I hacked around with this idea: - http://anonsvn.jboss.org/repos/jbossas/projects/demos/microcontainer/trun... New "Reset" state, after Installed. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252877#4252877 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252877

14 years, 8 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Cannot resolve dependency against unstarted bundle

by thomas.diesler＠jboss.com

If Bundle.RESOLVED maps to ControllerState.CLASSLOADER and Bundle.ACTIVE maps to ControllerState.INSTALLED we need to somehow resolve PackageRequirements against context's in state CLASSLOADER. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252874#4252874 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252874

14 years, 8 months

1
0
0 / 0

[JBoss OSGi Development] - Cannot resolve dependency against unstarted bundle

by thomas.diesler＠jboss.com

https://jira.jboss.org/jira/browse/JBOSGI-136 The VFSDeploymentClassLoaderPolicyModule creates the dependencies like this | protected void createDependencies() | { | ControllerState classLoaderState = getClassLoaderState(); | | List<Requirement> requirements = getRequirements(); | if (requirements != null) | { | requirementDependencies = new ArrayList<RequirementDependencyItem>(); | for (Requirement requirement : requirements) | { | RequirementDependencyItem item = new RequirementDependencyItem(this, requirement, classLoaderState); | addIDependOn(item); | requirementDependencies.add(item); | } | } | } | The RequirementDependencyItem always initialized the the dependentState with ControllerState.INSTALLED | public RequirementDependencyItem(Module module, Requirement requirement, ControllerState state) | { | super(module != null ? module.getContextName() : null, null, state, ControllerState.INSTALLED); | which ultimately leads to RequirementDependencyItem.resolve() not being able to find the dependent ControllerContext | ControllerContext context = controller.getContext(iDependOn, getDependentState()); | So it seems that RequirementDependencyItems can only resolve againt INSTALLED contexts. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252873#4252873 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252873

14 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

jboss-osgi-dev September 2009