You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "asaf.lahav" <as...@gmail.com> on 2007/04/10 00:52:08 UTC
newbie: installing and starting new bundles from code
Hi all,
I have been going through the "Launching
<http://cwiki.apache.org/FELIX/launching-and-embedding-felix.html#Launchinga
ndEmbeddingFelix-customlauncher> and Embedding Felix" document.
Can anyone provide information on how to install/uninstall start/stop new
bundles from code?
Thanks,
Asaf
Re: newbie: installing and starting new bundles from code
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On Apr 11, 2007, at 6:26 PM, Richard S. Hall wrote:
>
> On Apr 11, 2007, at 4:34 PM, Steven E. Harris wrote:
>
>> "Richard S. Hall" <he...@ungoverned.org> writes:
>>
>>>> You can give the bundle any arbitrary location you want and use
>>>> installBundle(String, InputStream)...this is what the OBR impl
>>>> does,
>>>> since it doesn't want the location is actually meaningless.
>>>
>>> That doesn't make sense..."since the location is actually
>>> meaningless"...
>>
>> But based upon the interface contract of installBundle() as described
>> by Mr. Hargrave, the location string is perhaps meaningless but must
>> remain strongly correlated to a particular symbolic-name/version
>> pair. He said that trying to install a bundle whose symbolic name and
>> version match an already installed bundle must fail if the location
>> string differs from the one used by the previously installed bundle.
>
> That is not true...there is no correlation between location string
> and symbolic name/version.
>
> Yes, if you try to install a bundle with a symbolic name/version it
> will fail, no matter what the location string is. However, if you
> update a bundle, it can update the bundle any symbolic name/version
> (except those which are already installed).
D'oh...I need to practice my typing apparently...that should say,
"Yes, if you try to install a bundle that matches an existing
symbolic name/version it will fail..."
-> richard
>
>> Does this location string match requirement not apply to the
>> installBundle(String, InputStream) overload?
>
> Again, symbolic name/version must be unique for all installed
> bundles, this has nothing to do with location strings.
>
> However, two bundles cannot have the same location string, thus
> location strings uniquely identify an installed bundle, but this is
> totally unrelated to the symbolic name/version of the bundle.
>
> To summarize:
>
> You cannot install two bundles with the same location string.
> You cannot install two bundles with the same symbolic name/version.
>
> The two statements are independent of each other.
>
>>
>>>> What you need is to check to see if the symbolic name + version is
>>>> already installed.
>>
>> Right, but what if I don't know the symbolic name and version of the
>> candidate bundle? It sounds like I'd have to parse the MANIFEST.MF
>> file myself first to get the candidate bundle's symbolic name and
>> version.
>
> If you wanted to be sure that it wouldn't fail for this reason,
> then yes you would have to. But what is the point? It could fail
> for other reasons too, so are you going to check all of those
> reasons in advance too?
>
> -> richard
Re: newbie: installing and starting new bundles from code
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On Apr 11, 2007, at 6:55 PM, Steven E. Harris wrote:
> "Richard S. Hall" <he...@ungoverned.org> writes:
>
>> Yes, if you try to install a bundle with a symbolic name/version it
>> will fail, no matter what the location string is.
>
> I may have misquoted Mr. Hargrave, but I think he refined this
> situation to say, if the location string of the new bundle and the
> currently installed bundle's location strings match, no error is
> signaled, and the current Bundle is returned.
Yes, sorry, that is the case. If location strings matches it returns
the existing bundle object and no other actions is taken. This has
always been the case, since R1.
>
>> To summarize:
>>
>> You cannot install two bundles with the same location string.
>> You cannot install two bundles with the same symbolic name/version.
>>
>> The two statements are independent of each other.
>
> Got it.
>
>> If you wanted to be sure that it wouldn't fail for this reason, then
>> yes you would have to. But what is the point? It could fail for
>> other reasons too, so are you going to check all of those reasons in
>> advance too?
>
> Here's why it's different: If it fails for the first reason, because
> the bundle is already installed, then I know I can carry on knowing
> all is well. The intention was to get some bundle installed. If it
> turns out it was already installed, then there is no problem; I was
> done before I started.
>
> But if installation fails for some other reason, I'm stuck unable to
> discern whether the installation failed due to a duplication conflict
> or due to data corruption. I don't know afterward whether I can assume
> this bundle is already installed.
Yes, that sounds reasonable. So, then i am back to my other point
that you should probably accept that you have to have additional
metadata on the server side to perform this check before you try to
install. This is not unreasonable, I don't think.
> To further disclose the motivating situation, my current design for my
> client-server interaction has the server saying, "Here are a bunch of
> resources (which are probably all bundles). These resources are
> prerequisites for some services I want you to use." The server wants
> the client to locate some registered services by providing key-value
> pairs to form a filter string. The server knows which bundles host
> these services, but the server doesn't know if the client already has
> these bundles installed, so it recommends the client install these
> bundles every time it recommends the client use some services hosted
> by these bundles.
>
> One simple way to solve this problem is to have the client try out
> using the filter string before trying to install the associated
> bundles. If the filter gets a hit, the bundle is probably already
> installed. If the filter gets no hits, the client should try
> downloading and installing the bundles, then try the filter
> again. This approach misses out on the possibility of updating an
> installed bundle that provides a superseded version of the service --
> but then services should really be versioned to catch that case.
>
> You may also ask why the server isn't telling the client explicitly
> which symbolic-name/version pairs to install. I'm trying to keep OSGi
> out of the protocol, by not explicitly mentioning concepts that are
> specific to OSGi. Hence my preference for the server to prescribe
> opaque resources for the client to download, with a MIME type (via an
> HTTP Content-Type header) hinting as to whether to try installing the
> resource as an OSGi bundle.
>
> Best of all would be to push all the bundle procurement into OBR. The
> server could specify a symbolic-name/version pair as a prerequisite
> (or, more abstractly, package names and versions) to construct a
> filter to pass to RepositoryAdmin.discoverResources(), then adding
> those Resources to a Resolver for resolution and deployment. OBR
> handles the case of locally-installed resources filling
> requirements. I'm just not sold on the idea of maintaining a
> repository.xml file that each client must download.
Yes. Ultimately it sounds like you will be re-implementing a bunch of
stuff that OBR already tries to do for you, so you would probably be
better off just using it in the first place.
It might be possible for you to create a modified OBR that you pass
in the repository you want it to use (or the XML file), that way you
could just get this information directly from the server and pass it
to OBR to do its calculations, if you don't want it to download the
repository file.
However, if your repository file isn't large, it doesn't seem like an
issue to worry about now.
-> richard
>
> --
> Steven E. Harris
Re: newbie: installing and starting new bundles from code
Posted by "Steven E. Harris" <se...@panix.com>.
"Richard S. Hall" <he...@ungoverned.org> writes:
> Yes, if you try to install a bundle with a symbolic name/version it
> will fail, no matter what the location string is.
I may have misquoted Mr. Hargrave, but I think he refined this
situation to say, if the location string of the new bundle and the
currently installed bundle's location strings match, no error is
signaled, and the current Bundle is returned.
> To summarize:
>
> You cannot install two bundles with the same location string.
> You cannot install two bundles with the same symbolic name/version.
>
> The two statements are independent of each other.
Got it.
> If you wanted to be sure that it wouldn't fail for this reason, then
> yes you would have to. But what is the point? It could fail for
> other reasons too, so are you going to check all of those reasons in
> advance too?
Here's why it's different: If it fails for the first reason, because
the bundle is already installed, then I know I can carry on knowing
all is well. The intention was to get some bundle installed. If it
turns out it was already installed, then there is no problem; I was
done before I started.
But if installation fails for some other reason, I'm stuck unable to
discern whether the installation failed due to a duplication conflict
or due to data corruption. I don't know afterward whether I can assume
this bundle is already installed.
To further disclose the motivating situation, my current design for my
client-server interaction has the server saying, "Here are a bunch of
resources (which are probably all bundles). These resources are
prerequisites for some services I want you to use." The server wants
the client to locate some registered services by providing key-value
pairs to form a filter string. The server knows which bundles host
these services, but the server doesn't know if the client already has
these bundles installed, so it recommends the client install these
bundles every time it recommends the client use some services hosted
by these bundles.
One simple way to solve this problem is to have the client try out
using the filter string before trying to install the associated
bundles. If the filter gets a hit, the bundle is probably already
installed. If the filter gets no hits, the client should try
downloading and installing the bundles, then try the filter
again. This approach misses out on the possibility of updating an
installed bundle that provides a superseded version of the service --
but then services should really be versioned to catch that case.
You may also ask why the server isn't telling the client explicitly
which symbolic-name/version pairs to install. I'm trying to keep OSGi
out of the protocol, by not explicitly mentioning concepts that are
specific to OSGi. Hence my preference for the server to prescribe
opaque resources for the client to download, with a MIME type (via an
HTTP Content-Type header) hinting as to whether to try installing the
resource as an OSGi bundle.
Best of all would be to push all the bundle procurement into OBR. The
server could specify a symbolic-name/version pair as a prerequisite
(or, more abstractly, package names and versions) to construct a
filter to pass to RepositoryAdmin.discoverResources(), then adding
those Resources to a Resolver for resolution and deployment. OBR
handles the case of locally-installed resources filling
requirements. I'm just not sold on the idea of maintaining a
repository.xml file that each client must download.
--
Steven E. Harris
Re: newbie: installing and starting new bundles from code
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On Apr 11, 2007, at 4:34 PM, Steven E. Harris wrote:
> "Richard S. Hall" <he...@ungoverned.org> writes:
>
>>> You can give the bundle any arbitrary location you want and use
>>> installBundle(String, InputStream)...this is what the OBR impl does,
>>> since it doesn't want the location is actually meaningless.
>>
>> That doesn't make sense..."since the location is actually
>> meaningless"...
>
> But based upon the interface contract of installBundle() as described
> by Mr. Hargrave, the location string is perhaps meaningless but must
> remain strongly correlated to a particular symbolic-name/version
> pair. He said that trying to install a bundle whose symbolic name and
> version match an already installed bundle must fail if the location
> string differs from the one used by the previously installed bundle.
That is not true...there is no correlation between location string
and symbolic name/version.
Yes, if you try to install a bundle with a symbolic name/version it
will fail, no matter what the location string is. However, if you
update a bundle, it can update the bundle any symbolic name/version
(except those which are already installed).
> Does this location string match requirement not apply to the
> installBundle(String, InputStream) overload?
Again, symbolic name/version must be unique for all installed
bundles, this has nothing to do with location strings.
However, two bundles cannot have the same location string, thus
location strings uniquely identify an installed bundle, but this is
totally unrelated to the symbolic name/version of the bundle.
To summarize:
You cannot install two bundles with the same location string.
You cannot install two bundles with the same symbolic name/version.
The two statements are independent of each other.
>
>>> What you need is to check to see if the symbolic name + version is
>>> already installed.
>
> Right, but what if I don't know the symbolic name and version of the
> candidate bundle? It sounds like I'd have to parse the MANIFEST.MF
> file myself first to get the candidate bundle's symbolic name and
> version.
If you wanted to be sure that it wouldn't fail for this reason, then
yes you would have to. But what is the point? It could fail for other
reasons too, so are you going to check all of those reasons in
advance too?
-> richard
Re: newbie: installing and starting new bundles from code
Posted by "Steven E. Harris" <se...@panix.com>.
"Richard S. Hall" <he...@ungoverned.org> writes:
>> You can give the bundle any arbitrary location you want and use
>> installBundle(String, InputStream)...this is what the OBR impl does,
>> since it doesn't want the location is actually meaningless.
>
> That doesn't make sense..."since the location is actually meaningless"...
But based upon the interface contract of installBundle() as described
by Mr. Hargrave, the location string is perhaps meaningless but must
remain strongly correlated to a particular symbolic-name/version
pair. He said that trying to install a bundle whose symbolic name and
version match an already installed bundle must fail if the location
string differs from the one used by the previously installed bundle.
Does this location string match requirement not apply to the
installBundle(String, InputStream) overload?
>> What you need is to check to see if the symbolic name + version is
>> already installed.
Right, but what if I don't know the symbolic name and version of the
candidate bundle? It sounds like I'd have to parse the MANIFEST.MF
file myself first to get the candidate bundle's symbolic name and
version.
--
Steven E. Harris
Re: newbie: installing and starting new bundles from code
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Richard S. Hall wrote:
> Steven E. Harris wrote:
>> BJ Hargrave <ha...@us.ibm.com> writes:
>>
>>
>>> If location string is the same => returns the Bundle object of the
>>> installed bundle, otherwise throw BundleException.
>>>
>>
>> Then in order to accommodate a design like I'm describing, one where
>> some agent tries to install downloaded bundles without knowing whether
>> they're already installed, I have to make sure that the location
>> string is stable among equivalent bundles. I can't, say, download the
>> bundle to a temporary file (with a randomly constructed name) and try
>> to install it from there. Is that correct?
>>
>> I'll take the rest of my related questions to the osgi-dev list.
>
> You can give the bundle any arbitrary location you want and use
> installBundle(String, InputStream)...this is what the OBR impl does,
> since it doesn't want the location is actually meaningless.
That doesn't make sense..."since the location is actually meaningless"...
-> richard
>
> What you need is to check to see if the symbolic name + version is
> already installed.
>
> -> richard
Re: newbie: installing and starting new bundles from code
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Steven E. Harris wrote:
> BJ Hargrave <ha...@us.ibm.com> writes:
>
>
>> If location string is the same => returns the Bundle object of the
>> installed bundle, otherwise throw BundleException.
>>
>
> Then in order to accommodate a design like I'm describing, one where
> some agent tries to install downloaded bundles without knowing whether
> they're already installed, I have to make sure that the location
> string is stable among equivalent bundles. I can't, say, download the
> bundle to a temporary file (with a randomly constructed name) and try
> to install it from there. Is that correct?
>
> I'll take the rest of my related questions to the osgi-dev list.
You can give the bundle any arbitrary location you want and use
installBundle(String, InputStream)...this is what the OBR impl does,
since it doesn't want the location is actually meaningless.
What you need is to check to see if the symbolic name + version is
already installed.
-> richard
Re: newbie: installing and starting new bundles from code
Posted by "Steven E. Harris" <se...@panix.com>.
BJ Hargrave <ha...@us.ibm.com> writes:
> Think of location as a primary key for a Bundle.
That's a useful analogy, but it provokes more questions. I'll take
these over to osgi-dev.
--
Steven E. Harris
Re: newbie: installing and starting new bundles from code
Posted by BJ Hargrave <ha...@us.ibm.com>.
Think of location as a primary key for a Bundle. It can also be used to
compute an InputStream (i.e. a URL) if one is not specified.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
"Steven E. Harris" <se...@panix.com>
2007-04-11 16:37
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: newbie: installing and starting new bundles from code
BJ Hargrave <ha...@us.ibm.com> writes:
> Sure you can. You need to use the installBundle(String, InputStream)
> method though. You must supply the InputStream to the local temp
> file.
But is the location string ignored in that case, or are you just
saying that I can divorce the location string from the actual bundle
data source?
I brought up the temporary file example just because it usually
involves a randomly constructed file name -- one that, if used as a
location string, would not match a previously installed bundle's
location string.
--
Steven E. Harris
Re: newbie: installing and starting new bundles from code
Posted by "Steven E. Harris" <se...@panix.com>.
BJ Hargrave <ha...@us.ibm.com> writes:
> Sure you can. You need to use the installBundle(String, InputStream)
> method though. You must supply the InputStream to the local temp
> file.
But is the location string ignored in that case, or are you just
saying that I can divorce the location string from the actual bundle
data source?
I brought up the temporary file example just because it usually
involves a randomly constructed file name -- one that, if used as a
location string, would not match a previously installed bundle's
location string.
--
Steven E. Harris
Re: newbie: installing and starting new bundles from code
Posted by BJ Hargrave <ha...@us.ibm.com>.
Sure you can. You need to use the installBundle(String, InputStream)
method though. You must supply the InputStream to the local temp file.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
"Steven E. Harris" <se...@panix.com>
2007-04-11 16:15
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: newbie: installing and starting new bundles from code
BJ Hargrave <ha...@us.ibm.com> writes:
> If location string is the same => returns the Bundle object of the
> installed bundle, otherwise throw BundleException.
Then in order to accommodate a design like I'm describing, one where
some agent tries to install downloaded bundles without knowing whether
they're already installed, I have to make sure that the location
string is stable among equivalent bundles. I can't, say, download the
bundle to a temporary file (with a randomly constructed name) and try
to install it from there. Is that correct?
I'll take the rest of my related questions to the osgi-dev list.
--
Steven E. Harris
Re: newbie: installing and starting new bundles from code
Posted by "Steven E. Harris" <se...@panix.com>.
BJ Hargrave <ha...@us.ibm.com> writes:
> If location string is the same => returns the Bundle object of the
> installed bundle, otherwise throw BundleException.
Then in order to accommodate a design like I'm describing, one where
some agent tries to install downloaded bundles without knowing whether
they're already installed, I have to make sure that the location
string is stable among equivalent bundles. I can't, say, download the
bundle to a temporary file (with a randomly constructed name) and try
to install it from there. Is that correct?
I'll take the rest of my related questions to the osgi-dev list.
--
Steven E. Harris
Re: newbie: installing and starting new bundles from code
Posted by BJ Hargrave <ha...@us.ibm.com>.
Niclas Hedhman <he...@gmail.com> wrote on 2007-04-11 21:31:59:
> On Thursday 12 April 2007 03:42, BJ Hargrave wrote:
> > If location string is the same => returns the Bundle object of the
> > installed bundle, otherwise throw BundleException.
>
> I think Steven may have a point that either a couple of subclasses
> for failure
> cause or some querable attribute in the BundleException has a place in a
> future amendment to the spec.
OSGi already has bug 410 open on this.
>
> Cheers
> Niclas
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
Re: newbie: installing and starting new bundles from code
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 12 April 2007 03:42, BJ Hargrave wrote:
> If location string is the same => returns the Bundle object of the
> installed bundle, otherwise throw BundleException.
I think Steven may have a point that either a couple of subclasses for failure
cause or some querable attribute in the BundleException has a place in a
future amendment to the spec.
Cheers
Niclas
Re: newbie: installing and starting new bundles from code
Posted by BJ Hargrave <ha...@us.ibm.com>.
If location string is the same => returns the Bundle object of the
installed bundle, otherwise throw BundleException.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
"Steven E. Harris" <se...@panix.com>
2007-04-11 15:13
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: newbie: installing and starting new bundles from code
Niclas Hedhman <ni...@hedhman.org> writes:
> R4 spec (not R4.1) section
> - 6.1.6.15
> BundleContext.installBundle( String location )
> throws BundleException
>
> - 6.1.6.16
> BundleContext.installBundle( String location, InputStream input )
> throws BundleException
What does installBundle() do if a bundle is already installed with the
same symbolic name and version as the new "candidate" bundle?
--
Steven E. Harris
Re: newbie: installing and starting new bundles from code
Posted by "Steven E. Harris" <se...@panix.com>.
Niclas Hedhman <ni...@hedhman.org> writes:
> R4 spec (not R4.1) section
> - 6.1.6.15
> BundleContext.installBundle( String location )
> throws BundleException
>
> - 6.1.6.16
> BundleContext.installBundle( String location, InputStream input )
> throws BundleException
What does installBundle() do if a bundle is already installed with the
same symbolic name and version as the new "candidate" bundle?
--
Steven E. Harris
Re: newbie: installing and starting new bundles from code
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Steven E. Harris wrote:
> Clement Escoffier <cl...@gmail.com> writes:
>
>
>> try {
>> bundle = context.installBundle(loc);
>> out.println(loc + " is installed as " + bundle.getBundleId());
>> } catch (BundleException e) {
>> err.println("Failed to install " + loc + " : " + e.getMessage());
>> return;
>> }
>>
>
> On a related note, I can't figure out what happens if one tries to
> install a bundle whose Symbolic Name and Version match an already
> installed bundle, but differ in location string.
>
There would be an install error, because symbolic name + version must be
unique.
> I understand that if the symbolic name and version match an existing
> bundle, installing the new bundle should be indistinguishable from
> just getting access to the existing bundle, but it would be nice to be
> able to figure out via the installBundle() interface whether
> installation fails due to a corrupted input source or due to a
> conflict with an already installed bundle.
>
There is no way to know that from the exception except by reading the
exception message.
-> richard
Re: newbie: installing and starting new bundles from code
Posted by "Steven E. Harris" <se...@panix.com>.
Clement Escoffier <cl...@gmail.com> writes:
> try {
> bundle = context.installBundle(loc);
> out.println(loc + " is installed as " + bundle.getBundleId());
> } catch (BundleException e) {
> err.println("Failed to install " + loc + " : " + e.getMessage());
> return;
> }
On a related note, I can't figure out what happens if one tries to
install a bundle whose Symbolic Name and Version match an already
installed bundle, but differ in location string.
I'm considering a design where my client downloads bundles and tries
to install them, but doesn't know beforehand the downloaded bundle's
symbolic name or version. Hence the client has no way of knowing
(short of parsing the MANIFEST.MF file itself) the new/pending
bundle's identity to know whether it will clash with a bundle that's
already installed.
I understand that if the symbolic name and version match an existing
bundle, installing the new bundle should be indistinguishable from
just getting access to the existing bundle, but it would be nice to be
able to figure out via the installBundle() interface whether
installation fails due to a corrupted input source or due to a
conflict with an already installed bundle.
--
Steven E. Harris
Re: newbie: installing and starting new bundles from code
Posted by Clement Escoffier <cl...@gmail.com>.
Hello,
The following code shows you an example of bundle installation and starting.
- loc is the path of the bundle (URL)
- context is the bundle context
out.println("Installing " + loc + "...");
Bundle bundle = null;
try {
bundle = context.installBundle(loc);
out.println(loc + " is installed as " + bundle.getBundleId());
} catch (BundleException e) {
err.println("Failed to install " + loc + " : " +
e.getMessage());
return;
}
if(!installOnly) {
out.println("Starting " + loc + "...");
try {
bundle.start();
} catch (BundleException e) {
err.println("Failed to start bundle " +
bundle.getBundleId() + " : " + e.getMessage());
return;
}
}
Clement
RE: newbie: installing and starting new bundles from code
Posted by "asaf.lahav" <as...@gmail.com>.
Excellent!
Thanks
-----Original Message-----
From: Niclas Hedhman [mailto:hedhman@gmail.com] On Behalf Of Niclas Hedhman
Sent: Tuesday, April 10, 2007 8:39 AM
To: felix-dev@incubator.apache.org
Subject: Re: newbie: installing and starting new bundles from code
On Tuesday 10 April 2007 13:12, asaf.lahav wrote:
> I have been going through the specs.
> Maybe I am missing something... But I haven't encountered a spec that
> provides information of how to perform bundle management via code. Is
> there?
R4 spec (not R4.1) section
- 6.1.6.15
BundleContext.installBundle( String location )
throws BundleException
- 6.1.6.16
BundleContext.installBundle( String location, InputStream input )
throws BundleException
- 6.1.4.23
Bundle.start() throws BundleException
- 6.1.4.24
Bundle.stop() throws BundleException
- 6.1.4.25
Bundle.uninstall() throws BundleException
- 6.1.4.26
Bundle.update() throws BundleException
- 6.1.4.27
Bundle.update( InputStream in ) throws BundleException
If you are talking about how to get hold of a BundleContext when embedding
Felix, then you need to look at Felix specific stuff, such as providing
BundleActivators in the Felix.start() method...
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: newbie: installing and starting new bundles from code
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 10 April 2007 13:12, asaf.lahav wrote:
> I have been going through the specs.
> Maybe I am missing something... But I haven't encountered a spec that
> provides information of how to perform bundle management via code. Is
> there?
R4 spec (not R4.1) section
- 6.1.6.15
BundleContext.installBundle( String location )
throws BundleException
- 6.1.6.16
BundleContext.installBundle( String location, InputStream input )
throws BundleException
- 6.1.4.23
Bundle.start() throws BundleException
- 6.1.4.24
Bundle.stop() throws BundleException
- 6.1.4.25
Bundle.uninstall() throws BundleException
- 6.1.4.26
Bundle.update() throws BundleException
- 6.1.4.27
Bundle.update( InputStream in ) throws BundleException
If you are talking about how to get hold of a BundleContext when embedding
Felix, then you need to look at Felix specific stuff, such as providing
BundleActivators in the Felix.start() method...
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
RE: newbie: installing and starting new bundles from code
Posted by "asaf.lahav" <as...@gmail.com>.
I have been going through the specs.
Maybe I am missing something... But I haven't encountered a spec that
provides information of how to perform bundle management via code. Is there?
-----Original Message-----
From: Niclas Hedhman [mailto:hedhman@gmail.com] On Behalf Of Niclas Hedhman
Sent: Tuesday, April 10, 2007 4:53 AM
To: felix-dev@incubator.apache.org
Subject: Re: newbie: installing and starting new bundles from code
On Tuesday 10 April 2007 06:52, asaf.lahav wrote:
> Can anyone provide information on how to install/uninstall start/stop new
> bundles from code?
Look into the R4 Core specification. If you search for "installBundle" you
will find numerous references to it, explaining what you need to know.
You are probably also interested in the updateBundle as well. Same advice.
Bundle and BundleContext are the essentials, but be careful about holding
onto
Bundle instances since you easily create memory leaks as other bundles (e.g.
Console) are uninstalling bundles.
Cheers
Niclas
Re: newbie: installing and starting new bundles from code
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 10 April 2007 06:52, asaf.lahav wrote:
> Can anyone provide information on how to install/uninstall start/stop new
> bundles from code?
Look into the R4 Core specification. If you search for "installBundle" you
will find numerous references to it, explaining what you need to know.
You are probably also interested in the updateBundle as well. Same advice.
Bundle and BundleContext are the essentials, but be careful about holding onto
Bundle instances since you easily create memory leaks as other bundles (e.g.
Console) are uninstalling bundles.
Cheers
Niclas