On Thu, Apr 15, 2010 at 17:51, Lin Sun <[email protected]> wrote:
> Ok that sounds good. I simply cannot find a reason to do prepare for
> bundleprocessor yet :-)
>
> Continue our discussion on Aries-283:
>
> I wonder if we want the user to separate the subsystem-content and
> subsystem-resource. With existing application code, I think the
> content and resource are all in the content, and it is the underlying
> code to decide if a convert is needed. This may make users job a bit
> simpler. For example, for a war file, the user doesn't have to
> know/care that it needs to be converted, and can specify it in the
> subsystem-content.
>
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.
> Regarding VersionRange for Resource, I think it makes sense to have
> some SubsystemMetadata interface that represents the initial metadata
> for the subsystem and in that the subsystem content can be version
> ranges. For Resource, since it is the best match found by the
> resource resolver and the one we'll install, it makes sense to have a
> fixed version for it, like what we have today.
>
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.
>
> WDYT?
>
> Lin
>
>
>
> On Thu, Apr 15, 2010 at 9:24 AM, Guillaume Nodet <[email protected]> wrote:
> >
> > Actually, there may be some use cases for the prepare() method.
> > The reason is that when installing a subsystem, a processor may be
> > called multiple times for different resources, yet, a single session
> would
> > be used. The prepare() would then allow some processing after all
> > resources have been processed.
> >
> > If you look at the subsystem processor, it actually restarts the
> subsystems
> > that were previously stopped (during an update for example). Restarting
> > those
> > in the process() method could have undesirable effect such as forcing the
> > resolution
> > of some bundles too early.
> >
> > So we may want to keep it ...
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
