On Tue, Apr 6, 2010 at 15:30, Lin Sun <[email protected]> wrote: > Please see replies in line. > > > On Tue, Apr 6, 2010 at 2:47 AM, Guillaume Nodet <[email protected]> wrote: > >> Yeah, it's the same as the application installer. It works with Felix > > Fileinstall > > which is used in Karaf (and Geronimo) to support file based deployments. > > This is the way i've done very basic testing (by using Karaf and creating > a > > exploded > > subsystem archive in the deploy folder). > > Ah I see. I have been wondering how we can itest this stuff as I > don't see the prototype equinox that contains the impl of the RFC 138 > available in maven central. > > > Yes, I think so. Feel free to go ahead. As I said, I only committed > that > > code so > > that you can have a look and start working on it if you want. > > Ok great. I'll start making changes and if you don't like them, let me know > :) > > Sounds good.
> > > > Not only. The coupling between the admin and its internal subsystems is > > quite loose. > > Actually, subsystems are not put into the internal map when installed, > but > > only through those > > processed bundle notifications. I'm not sure it's actually a good idea, > > because this means > > that a subsystem which is being installed will be made available for > > management before > > it is fully installed. So this certainly need to be reworked in the > future > > I think. > > > Yes I think the code is a bit confusing as when we detect bundle event > change we add the subsystem to the map or remove the subsystem off the > map. We don't deal with the map for the install() method, but for > the uninstall() method, we remove the subsystem off the map. > > I think we don't necessarily need the sync bundle listener. We can > just process all the initial bundles then use install/uninstall/update > to manage the map, assuming we only care about the subsystems that are > installed via subsystemAdmin. If you like that, I can try make the > change. > Yeah, though I was not really keen on persisting the data for subsystems. That's why I used a subsystem:=true directive on the symbolic name of the underlying composite. I think we still need the bundle listener in case the user uninstall a composite himself, or even in the case where a composite installation will install another peer composite in order to satisfy some dependencies. So that's why I had chosen to just rely on those events, but the downside is that the subsystems appear before they are fully installed :-( > > > Once again, I don't consider any of this code as really working or final. > > The only think which is working > > is the fact that you can install a subsystem and a composite will be > created > > with the jars listed > > in the manifest. It's a bit dumb and the NoOpResolver means that the > only > > way to install a subsystem is > > by giving the location in the manifest: > > > > Manifest-Version: 1.0 > > Subsystem-ManifestVersion: 1.0 > > Subsystem-SymbolicName: woodstox > > Subsystem-Version: 4.0.7 > > Subsystem-Content: > > > stax-api;location=mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.stax-api-1.0/1.4.0, > > stax2-api;location=mvn:org.codehaus.woodstox/stax2-api/3.0.1, > > > woodstox-core-asl;location=mvn:org.codehaus.woodstox/woodstox-core-asl/4.0.7 > > > > It certainly don't imply that this is what should be used by end users. > I > > agree using urls inside the manifest defeats the purpose of > > the resolver, but currently we have none, so I found that quite handy. > > So the current code will be able to deploy those bundles, that's all. > > Yep we need to add other ResourceResolvers going forward. So which > framework impl jar is providing the CompositeAdmin service and > creating the composite bundle in the test? Is your test case checked > in? > I don't really wrote any test case yet, those were just manual testing using the equinox prototype. I've actually uploaded it to the servicemix private repo for the time being: http://svn.apache.org/repos/asf/servicemix/m2-repo/org/eclipse/osgi/v43prototype-3.6.0.201003231329/ It would be nice if we can set up pax-exam to use that one, but I haven't tried yet. > > Thanks > > Lin > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
