Hi Graham I think the example I gave was confusing. I agree the subsystem content should not tie to a particular implementation.
So if a user specifies "Subsystem-Content:obr:content1", it will delegate to the obr url handler/resourceResolver provided by by the implementation, which could be felix obr or p2. Also, if no URI is specified for resolver by the user like "Subsystem-Content: content1", we should delegate to the resourceResolver that has the highest rank in OSGi service registry. I think the specifying of the URI makes more sense for resources like webbundle:resource1, especially it allows user to specify params like webbundle:resource1;web-contextpath=/tw1 Lin On Mon, Apr 19, 2010 at 9:35 AM, Graham Charters <[email protected]> wrote: > Hi Lin, I'm not quite following, so another comment below... > > On 19 April 2010 14:18, Lin Sun <[email protected]> wrote: >> Hi Graham >> >> I totally agree with what you said below that we need to allow people >> to plugin in their own resolver and use that to resolve/find the >> content. >> >> What is being proposed here in a bit further is to use url schema to >> determine which resolver it should go to. for example obr:content1 >> would goes to obr url handler to find/resolve content1; p2:content1 >> would go to the p2 url handler to find/resolve content1. >> > > Maybe I'm misunderstanding, but this sounds to me like the subsystem > definition will state whether to go to obr or p2 and that's what I > have a problem with. I think the subsystem should just say it > contains content1 and it's up to the environment into which the > subsystem is deployed to determine how to obtain content1. One > environment might support obr, another might support p2. We should > not require two entries or two separate subsystem definitions in order > to allow that flexibility. Basically, I'm saying it's not the > responsibility of the subsystem author to state where the things will > be hosted. Does that make sense? > >> I also like the rule you have that if the resource or bundle is listed >> in the content or resource, then it is installed inside. If not, then >> installed outside. >> >> Lin >> >> On Mon, Apr 19, 2010 at 9:04 AM, Graham Charters >> <[email protected]> wrote: >> >>> >>> It would be good to keep the rules clean and simple. For example, if >>> the thing is listed in the content, then it's installed inside, if >>> it's not, then it's installed outside. This probably covers the 80:20 >>> and is easy to explain. >>> >>>> For the ResourceResolver, I think it's nice to be pluggable, but it >>>> could still be an implementation specific feature without being part >>>> of the API or SPI documented for the user. >>>> >>> >>> For consumers of Aries, this is probably something other environments >>> will want to plug in different implementations. >>> >>>> I'll be in vacation today and next week, but I'll try to think a bit >>>> more about that. >>>> >>>> On Thursday, April 15, 2010, Lin Sun <[email protected]> wrote: >>>>> So for Subsystem-content, it doesn't need to be converted, and can >>>>> come from the user specified obr repos or from the eba file. The >>>>> contents will be installed in the subsystem while the transitive >>>>> dependencies will be installed outside the subsystem, however the >>>>> required packages/services will be imported from composite bundle to >>>>> the subsystem. >>>>> >>>>> Examples: >>>>> >>>>> Subsystem-Content: bundlesymbolicname;version="1.0.0" >>>>> >>>>> or >>>>> >>>>> Subsystem-Content: bundlesymbolicname;version="[1.0.0, 2.0.0]" >>>>> >>>>> For Subsystem-resource, it needs to be converted and the type needs to >>>>> be specified so that we can delegate work to the corresponding >>>>> converter. The resources will be installed in the subsystem. Are we >>>>> assuming the subsystem-resource have to be supplied in the eba file? >>>>> If not, I am not sure how we can find the resource, given it is not a >>>>> bundle yet and won't be available in the OBR repo. >>>>> >>>>> Do we expect any transitive dependencies for the war? I think it can >>>>> have like a war requires servlet 3.0, a blueprint xml requires >>>>> blueprint APIs. Would it also be installed outside the subsystem >>>>> but required packages/services flown into the subsystem? >>>>> Examples: >>>>> >>>>> Subsystem-Resource: test.war;type=war >>>>> >>>>> However, if we use URI to represent subsystem content/resource, we >>>>> could just have Subsystem-content, as the URI would convey which URL >>>>> handlers would invoke already. >>>>> >>>>> Examples: >>>>> >>>>> Subsystem-Content: obr:bundlesymbolicname;version="[1.0.0, 2.0.0]", >>>>> webbundle:test.war;web-contextpath=/test1 >>>>> >>>>> Anything without the obr: should be found in the .eba archive. I >>>>> agree that later one is powerful and you can pass in params too. >>>>> >>>>> Regarding ResourceResolver, I don't see the need for user to supply it >>>>> while it would be a useful interface for our subsystem. >>>>> >>>>> Lin >>>>> >>>>> On Thu, Apr 15, 2010 at 12:39 PM, Guillaume Nodet <[email protected]> >>>>> wrote: >>>>>> >>>>>> Well, I agree it's easier, but it's way less powerfull. The first thing >>>>>> i'd >>>>>> like to make sure is that installing a subsystem >>>>>> is a predictable operation, i.e. it's not affected by what is deployed or >>>>>> not (or at least in a controlled way). >>>>>> The other thing, is that I think we should allow other types of resources >>>>>> than bundles to be installed, hence the SPI >>>>>> for ResourceProcessor. >>>>>> >>>>>> >>>>>> Not let's take an example: we implement a ResourceConverter which is >>>>>> able to >>>>>> take a blueprint xml file and turn it into a bundle. >>>>>> Now, we can embed the blueprint xml into the subsystem archive and >>>>>> expect it >>>>>> to be installed if needed. >>>>>> This raises a few questions / problems: >>>>>> * the subsystem admin need to be able to identify which >>>>>> ResourceConverter >>>>>> will be used, and in a way that the user >>>>>> can be sure which one will be used. If a converter that can >>>>>> transform >>>>>> a spring xml file into a bundle has been >>>>>> registered, how will the subsystem admin know which one to choose >>>>>> * how are the symbolic name / version found for the resource ? >>>>>> >>>>>> Another use case: I want to install some ConfigAdmin configurations as a >>>>>> property file, while the ConfigAdmin processor >>>>>> only handles xml files, so I need to convert my property file into a xml >>>>>> file in a know format. >>>>>> So I need to specify: >>>>>> * the type of the resource that will be installed by the >>>>>> ResourceProcessor >>>>>> * the type of the original resource (property file) that need to be >>>>>> converted, or the name of the converter somehow >>>>>> * but i also need to be able to point to the property file somehow >>>>>> >>>>>> Another use case: I have a war available in a maven repo and I want to >>>>>> install it as part of my subsystem, without >>>>>> embedding it in the archive. I then need: >>>>>> * a way to identify and point to the war >>>>>> >>>>>> Note that converters are not critical, they are only for ease of use, as >>>>>> any >>>>>> conversion that they will do could be done >>>>>> offline. >>>>>> Second, we need to be able to point to resources that are not osgi >>>>>> bundles, >>>>>> such as wars or config files, either from >>>>>> inside the subsystem archive or from outside the archive. >>>>>> >>>>>> My first idea was to simply get rid of the converters and use URI. URIs >>>>>> are >>>>>> much more powerful than anything we could come up with. >>>>>> In addition, OSGI supports custom URI handlers and we could use an >>>>>> indirect >>>>>> uri for that: >>>>>> webbundle:obr:symbolicname/version >>>>>> The webbundle scheme will leverage the existing spec and will transform >>>>>> the >>>>>> war on the fly. >>>>>> The obr url will delegate to OBR to find a resource with the give >>>>>> symbolic >>>>>> name and version. >>>>>> We could use a maven url too: >>>>>> webbundle:mvn:groupid:artifactid:version:war >>>>>> >>>>>> I can understand some people are reluctant to using URI in the first >>>>>> place, >>>>>> so using symbolicname/version. >>>>>> The problem is that a symbolic name and version does not really give you >>>>>> a >>>>>> location to download the jar from. >>>>>> >>>>>> So, back to the problem. I think the user needs to care about the >>>>>> transformation. And it should not matter if >>>>>> the resource comes from the subsystem archive or from an external >>>>>> location. >>>>>> The idea in the eba archive is that >>>>>> the content of the archive is used to create some kind of repository >>>>>> which >>>>>> can be used by the resolver to resolve >>>>>> the needed dependencies. So it's just *another* repository, but I don't >>>>>> think that transformations should apply >>>>>> only to the resources inside the archive. We should be able to >>>>>> transform a >>>>>> war without including it imho. >>>>>> >>>>>> Anyway, I hope I raised a few interesting questions. >>>>> >>>>>> >>>>>> I'd really like to avoid adding a whole object model representation of >>>>>> the >>>>>> manifest in the api. >>>>>> There's no point in doing that, as everybody can parse the manifest. >>>>>> I'd rather remove the ResourceResolver completely from the SPI, as I >>>>>> don't >>>>>> think >>>>>> this is something which is needed to be plugged in by the user. >>>>>> >>>>>> As a drastic operation for now, we could only keep the SPI with: >>>>>> * Resource which defines how to access something >>>>>> * ResourceProcessor which can actually process the thing >>>>>> >>>>>> Converters can be done offline and the Resolver is more an implementation >>>>>> detail imho. >>>>> >>>> >>>> -- >>>> Cheers, >>>> Guillaume Nodet >>>> ------------------------ >>>> Blog: http://gnodet.blogspot.com/ >>>> ------------------------ >>>> Open Source SOA >>>> http://fusesource.com >>>> >>> >> >
