Community
Participate
Working Groups
This occurs on the latest development builds including the fix to bug 342458. To get started on this bug, look in the kernel.shell bundle at StandardRamAccessorHelper.getArtifacts(String, String, String). The input parameters, extracted from the HTTP request, are type, name, and version and so the code currently looks in the user region and, if a matching bundle is not found, then looks in the kernel region. Since the dojo tree does not contain region ids for (bundle) artifacts, user region bundles incorrectly "shadow" kernel bundles in the admin console. The solution is probably to add the region id string to the dojo tree and ensure it flows in with the HTTP request and can then be passed down to getArtifact. The model already has region id present on instances of org.eclipse.virgo.kernel.model.Artifact and so the region id is available for adding to the dojo tree (although some intermediate code may need to be modified to deal with the region id). To reproduce the problem, use the admin console artifact console and navigate as follows: 1. plans 2. org.eclipse.virgo.web.tomcat 3. org.eclipse.virgo.web.core 4. org.eclipse.virgo.kernel.core 5. org.springframework.context 6. Click on the link "View this bundle artifact" under org.springframework.context 7. a bundle in the user region (e.g. bundle id 70) is shown. The problem is that when the admin console navigated from kernel.core to org.sf.context, the region was not taken into account and so the user region instance of org.sf.context was (incorrectly) found. kernel.core actually depends on the instance of org.sf.context in the kernel region since no packages are exported from the user region to the kernel. This can be verified using the Equinox console: osgi> bundle 25 org.eclipse.virgo.kernel.core_3.0.0.D-20110412160751 [25] Id=25, Status=ACTIVE Data Root=/Users/glynnormington/ripple/web-server/build-tomcat-server/target/package-expanded/virgo-tomcat-server-3.0.0.D-20110412170856/work/osgi/configuration/org.eclipse.osgi/bundles/25/data Registered Services ... Services in use: ... Exported packages ... Imported packages ... org.springframework.scheduling.concurrent; version="3.0.0.RELEASE" <org.springframework.context_3.0.0.RELEASE [24]>
This is now fixed as per 344142