| Summary: | correct com.springsource references | ||
|---|---|---|---|
| Product: | [RT] Virgo | Reporter: | Miles Parker <milesparker> |
| Component: | tooling | Assignee: | Miles Parker <milesparker> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | minor | ||
| Priority: | P3 | CC: | eclipse, leo.dos.santos, mlippert |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
| Bug Depends on: | 373856 | ||
| Bug Blocks: | 368761 | ||
|
Description
Miles Parker
Leo, can you take a look at the Jmx stuff in org.eclipse.virgo.ide.runtime.internal.core.command? There are still some com.springsource references in there, which makes me wonder how it's working. There is also one suage in RepositoryUtils, but I think that should be there to support the com.springsource.* style bundles. Miles, looks to me like the org.eclipse.virgo.ide.management.remote.StandardBundleAdmin is an MBean that registers itself with objectName = "com.springsource.server:type=BundleAdmin". I guess we package up the *management.remote jar and drop it into Virgo. A couple of our JMX commands (JMXBundleAdminExecuteCommand & JMXBundleAdminServerCommand) then look up the MBean with this signature. We can probably change these ids, & recompile the management.remote jar that we package with runtime.core There's another usage in JMXServerUpdateCommand of "com.springsource.kernel:artifact-type=bundle". We need to run a JMX browser on a running Virgo to see what MBeans it exposes, but I'm guessing that we will have to change it to some sort of "org.eclipse.virgo.kernel.foo" id |