You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by lili_ili <sv...@gmail.com> on 2011/07/13 16:01:07 UTC
Moving fragment to Resolved state in fileinstall watched directory?
Hi
I have a directory being watched by fileinstall. Fragment is copied to this
directory after its host, and it automatically moves to "Installed" state.
To make it "Resolved", I need to either run "resolve X" command, or restart
the server.
Is there a way to solve it and resolve fragments located in "watched"
directories?
thank you.
--
View this message in context: http://old.nabble.com/Moving-fragment-to-Resolved-state-in-fileinstall-watched-directory--tp32052770p32052770.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Managing Dynamism
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello John,
Probably makes sense to follow up on the ACE mailing list. We don't yet have "users" list so feel free to use the ace-dev list for that (I cc'ed this mail to it as well).
Greetings, Marcel
On 15 Jul 2011, at 15:36 , <jo...@exceter.com> <jo...@exceter.com> wrote:
> That sounds perfect for what I'm trying to do!
>
> Quoting Marcel Offermans <ma...@luminis.nl>:
>
>> On 14 Jul 2011, at 23:00 , <jo...@exceter.com> wrote:
>>
>>> I would like to hide the update mechanism from the end user. As far as the client is be concerned, the application should be versioned as a whole. For example, I would like the client to see that an update from version 1.2.3.4 to 1.2.3.5 is available. Behind the scenes the update would be a collection of bundles. The bundles would be versioned separately but the update(collection of bundles) would be tested as a unit in my test environment before being made available to the client.
>>
>> You're pretty much describing the way Apache ACE handles the deployment of bundles (and configuration). They are distributed in a deployment package. Deployment packages are versioned sets of artifacts. Every time you change something in the set of bundles (for that client) its version number is bumped.
>>
>>> I'd also like to be able to give the client a menu for falling back to a previous version.
>>
>> The management agent on the client can make that decision (to go back to any previous version in fact). Hooking that up to the UI isn't hard.
>>
>> Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Managing Dynamism
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello John,
Probably makes sense to follow up on the ACE mailing list. We don't yet have "users" list so feel free to use the ace-dev list for that (I cc'ed this mail to it as well).
Greetings, Marcel
On 15 Jul 2011, at 15:36 , <jo...@exceter.com> <jo...@exceter.com> wrote:
> That sounds perfect for what I'm trying to do!
>
> Quoting Marcel Offermans <ma...@luminis.nl>:
>
>> On 14 Jul 2011, at 23:00 , <jo...@exceter.com> wrote:
>>
>>> I would like to hide the update mechanism from the end user. As far as the client is be concerned, the application should be versioned as a whole. For example, I would like the client to see that an update from version 1.2.3.4 to 1.2.3.5 is available. Behind the scenes the update would be a collection of bundles. The bundles would be versioned separately but the update(collection of bundles) would be tested as a unit in my test environment before being made available to the client.
>>
>> You're pretty much describing the way Apache ACE handles the deployment of bundles (and configuration). They are distributed in a deployment package. Deployment packages are versioned sets of artifacts. Every time you change something in the set of bundles (for that client) its version number is bumped.
>>
>>> I'd also like to be able to give the client a menu for falling back to a previous version.
>>
>> The management agent on the client can make that decision (to go back to any previous version in fact). Hooking that up to the UI isn't hard.
>>
>> Greetings, Marcel
Re: Managing Dynamism
Posted by jo...@exceter.com.
That sounds perfect for what I'm trying to do!
Quoting Marcel Offermans <ma...@luminis.nl>:
> On 14 Jul 2011, at 23:00 , <jo...@exceter.com> wrote:
>
>> I would like to hide the update mechanism from the end user. As far
>> as the client is be concerned, the application should be versioned
>> as a whole. For example, I would like the client to see that an
>> update from version 1.2.3.4 to 1.2.3.5 is available. Behind the
>> scenes the update would be a collection of bundles. The bundles
>> would be versioned separately but the update(collection of bundles)
>> would be tested as a unit in my test environment before being made
>> available to the client.
>
> You're pretty much describing the way Apache ACE handles the
> deployment of bundles (and configuration). They are distributed in a
> deployment package. Deployment packages are versioned sets of
> artifacts. Every time you change something in the set of bundles
> (for that client) its version number is bumped.
>
>> I'd also like to be able to give the client a menu for falling back
>> to a previous version.
>
> The management agent on the client can make that decision (to go
> back to any previous version in fact). Hooking that up to the UI
> isn't hard.
>
> Greetings, Marcel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Managing Dynamism
Posted by Marcel Offermans <ma...@luminis.nl>.
On 14 Jul 2011, at 23:00 , <jo...@exceter.com> wrote:
> I would like to hide the update mechanism from the end user. As far as the client is be concerned, the application should be versioned as a whole. For example, I would like the client to see that an update from version 1.2.3.4 to 1.2.3.5 is available. Behind the scenes the update would be a collection of bundles. The bundles would be versioned separately but the update(collection of bundles) would be tested as a unit in my test environment before being made available to the client.
You're pretty much describing the way Apache ACE handles the deployment of bundles (and configuration). They are distributed in a deployment package. Deployment packages are versioned sets of artifacts. Every time you change something in the set of bundles (for that client) its version number is bumped.
> I'd also like to be able to give the client a menu for falling back to a previous version.
The management agent on the client can make that decision (to go back to any previous version in fact). Hooking that up to the UI isn't hard.
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Managing Dynamism
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/14/11 17:00, john.dunlap@exceter.com wrote:
>
> I would like to hide the update mechanism from the end user. As far as
> the client is be concerned, the application should be versioned as a
> whole. For example, I would like the client to see that an update from
> version 1.2.3.4 to 1.2.3.5 is available. Behind the scenes the update
> would be a collection of bundles. The bundles would be versioned
> separately but the update(collection of bundles) would be tested as a
> unit in my test environment before being made available to the client.
>
> I'd also like to be able to give the client a menu for falling back to
> a previous version.
Well, in that case, you control everything, so it should be do-able.
Regarding the "fall back" mechanism, OSGi doesn't give you a way to
access the bundle JAR files, so you'd likely need to make some sort of
installer bundle that actually deploys the bundles and keeps a copy of
what it deploys so it is able to rollback if desired.
-> richard
>
> Quoting "Richard S. Hall" <he...@ungoverned.org>:
>
>> On 7/14/11 13:33, john.dunlap@exceter.com wrote:
>>> I'm interested in using OSGI as an update mechanism in a swing
>>> based app. However, I'm concerned that managing the extremely
>>> dynamic nature of OSGI is too difficult.
>>>
>>> How can guarantee that the client's OSGI container will remain in a
>>> known state which is identical to the state of the OSGI container
>>> that I'm testing against? How can I guarantee that updates will be
>>> installed, resolved, and wired in exactly the same sequence in the
>>> client OSGI container and as they are in the OSGI container that
>>> I'm testing against? If I cannot guarantee these things then I do
>>> not understand how I can guarantee that my updates will succeed.
>>
>> It depends. If you are completely hiding the underlying dynamic OSGi
>> layer underneath and completely controlling what gets installed into
>> the framework, then you should be able to control it. However, if you
>> are exposing it to the end user (e.g., allowing the user to dynamic
>> deploy arbitrary bundles or plugins), then it becomes more complicated.
>>
>> If you are exposing the ability to deploy arbitrary bundles, then you
>> can always try to make your bundles' dependencies very rigid so you
>> only get them from where you expect (e.g., using Import-Package with
>> the explicit attributes or even Require-Bundle). Doing so, however,
>> might not always give you optimum results.
>>
>> For example, if the user deployed some newer version of a common
>> library and other bundles that depend on it. If your bundles can only
>> wire to the older version (even if the newer one would be compatible),
>> then you'll create a class space division in the system and your
>> bundles will potentially not be able to interoperate with the new
>> bundles. It can also create situations where things fail to resolve at
>> all, since rigid dependencies, by definition, do not give the OSGi
>> resolver much flexibility in selecting candidates.
>>
>> So, in short, if you cannot and do not want to cope with any dynamism
>> in your system, don't introduce any other than what is controlled by
>> yourself.
>>
>> -> richard
>>
>>>
>>> -John
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Managing Dynamism
Posted by Christopher BROWN <br...@reflexe.fr>.
Hello,
This is the use case I'm implementing... My first "real" OSGi project is a
web front end for a lightweight ERP platform that bundles a AJAX/JS GUI
framework (the "back office", no OSGi), where the front end (OSGi) runs in a
separate process with an embedded Jetty web server. The front end uses a
templating engine for rendering ad-hoc user interfaces with the ERP platform
used as a data source (with rules, ACL, etc). Templates can be modified in
real time... and code too, hence the choice of OSGi. That's the context of
what I'm doing.
The application is delivered as an executable JAR with Felix in the
classpath and the OSGi bundles are embedded in the JAR (but not in the
default classpath). The executable JAR unpacks the embedded bundles onto
the filesystem, configures Felix in embedded mode, then installs the bundles
(including fragments), starts them (excluding fragments), and sets up a
filewatcher so that changes to the directory are detected and bundles
started as needed (if the client drops in a new custom bundle, it
auto-starts, the client can also drop in hotfix upgrades).
These design goals, which seem similar to yours, work well with Felix. The
aim is to have everything (code & UI) fully dynamic, i.e.: the application
shouldn't ever need to be fully stopped, including patches, minor upgrades,
and possibly major ones too, as well as adding/updating/replacing plugins.
A bit more detail which may be helpful: all installed bundles are INSTALLED
in the framework sense, but then a little extra logic is applied: only the
most recent version of a bundle is explicitly STARTED (the others may be
started implicity if required, but this can create class space divisions).
Also, the filewatcher notifies removal of bundles, triggering stopping of
the bundles within the framework. As soon as a bundle is added again, the
host application tries to start any "required" bundles that were knocked
offline by a previous change (because deleting then replacing a bundle -- as
opposed to a one-step upgrade -- can take others offline, and there's no
automatic restart logic in this case). The host application requests
PackageAdmin->refresh as required to re-wire stuff.
For info, about filewatching, I use a little abstraction layer, which (when
possible) uses JXFileWatcher, falling back to a polling technique, and
capable of delegating to Java 7 filewatching at some point. The
filewatching/update logic is in the host application because JXFileWatcher
binds to a native library using JNI (so loadLibrary doesn't play nice with
bundle restarts if I implement in a bundle) and because we'd get stuck if
the "system update watcher" bundle got stopped unintentionally.
This works for me. I have a suspicion OSGi start levels could be of some
use here too, I haven't looked into that much however. Hope the details
(without naming products!) are helpful.
Just for the bonus: the container is also useful in unit testing: each
bundle gets tested in the framework in isolation, using another mock bundle
and a test fragment that attaches to the bundle being tested, in the same
package. Getting JUnit to play nice was a bit tricky though, especially
creating test instances with access to the bundle context. It's doable
though, without hacking JUnit...
--
Christopher
On 14 July 2011 23:00, <jo...@exceter.com> wrote:
>
> I would like to hide the update mechanism from the end user. As far as the
> client is be concerned, the application should be versioned as a whole. For
> example, I would like the client to see that an update from version 1.2.3.4
> to 1.2.3.5 is available. Behind the scenes the update would be a collection
> of bundles. The bundles would be versioned separately but the
> update(collection of bundles) would be tested as a unit in my test
> environment before being made available to the client.
>
> I'd also like to be able to give the client a menu for falling back to a
> previous version.
Re: Managing Dynamism
Posted by jo...@exceter.com.
I would like to hide the update mechanism from the end user. As far as
the client is be concerned, the application should be versioned as a
whole. For example, I would like the client to see that an update from
version 1.2.3.4 to 1.2.3.5 is available. Behind the scenes the update
would be a collection of bundles. The bundles would be versioned
separately but the update(collection of bundles) would be tested as a
unit in my test environment before being made available to the client.
I'd also like to be able to give the client a menu for falling back to
a previous version.
Quoting "Richard S. Hall" <he...@ungoverned.org>:
> On 7/14/11 13:33, john.dunlap@exceter.com wrote:
>> I'm interested in using OSGI as an update mechanism in a swing
>> based app. However, I'm concerned that managing the extremely
>> dynamic nature of OSGI is too difficult.
>>
>> How can guarantee that the client's OSGI container will remain in a
>> known state which is identical to the state of the OSGI container
>> that I'm testing against? How can I guarantee that updates will be
>> installed, resolved, and wired in exactly the same sequence in the
>> client OSGI container and as they are in the OSGI container that
>> I'm testing against? If I cannot guarantee these things then I do
>> not understand how I can guarantee that my updates will succeed.
>
> It depends. If you are completely hiding the underlying dynamic OSGi
> layer underneath and completely controlling what gets installed into
> the framework, then you should be able to control it. However, if you
> are exposing it to the end user (e.g., allowing the user to dynamic
> deploy arbitrary bundles or plugins), then it becomes more complicated.
>
> If you are exposing the ability to deploy arbitrary bundles, then you
> can always try to make your bundles' dependencies very rigid so you
> only get them from where you expect (e.g., using Import-Package with
> the explicit attributes or even Require-Bundle). Doing so, however,
> might not always give you optimum results.
>
> For example, if the user deployed some newer version of a common
> library and other bundles that depend on it. If your bundles can only
> wire to the older version (even if the newer one would be compatible),
> then you'll create a class space division in the system and your
> bundles will potentially not be able to interoperate with the new
> bundles. It can also create situations where things fail to resolve at
> all, since rigid dependencies, by definition, do not give the OSGi
> resolver much flexibility in selecting candidates.
>
> So, in short, if you cannot and do not want to cope with any dynamism
> in your system, don't introduce any other than what is controlled by
> yourself.
>
> -> richard
>
>>
>> -John
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Managing Dynamism
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/14/11 13:33, john.dunlap@exceter.com wrote:
> I'm interested in using OSGI as an update mechanism in a swing based
> app. However, I'm concerned that managing the extremely dynamic nature
> of OSGI is too difficult.
>
> How can guarantee that the client's OSGI container will remain in a
> known state which is identical to the state of the OSGI container that
> I'm testing against? How can I guarantee that updates will be
> installed, resolved, and wired in exactly the same sequence in the
> client OSGI container and as they are in the OSGI container that I'm
> testing against? If I cannot guarantee these things then I do not
> understand how I can guarantee that my updates will succeed.
It depends. If you are completely hiding the underlying dynamic OSGi
layer underneath and completely controlling what gets installed into the
framework, then you should be able to control it. However, if you are
exposing it to the end user (e.g., allowing the user to dynamic deploy
arbitrary bundles or plugins), then it becomes more complicated.
If you are exposing the ability to deploy arbitrary bundles, then you
can always try to make your bundles' dependencies very rigid so you only
get them from where you expect (e.g., using Import-Package with the
explicit attributes or even Require-Bundle). Doing so, however, might
not always give you optimum results.
For example, if the user deployed some newer version of a common library
and other bundles that depend on it. If your bundles can only wire to
the older version (even if the newer one would be compatible), then
you'll create a class space division in the system and your bundles will
potentially not be able to interoperate with the new bundles. It can
also create situations where things fail to resolve at all, since rigid
dependencies, by definition, do not give the OSGi resolver much
flexibility in selecting candidates.
So, in short, if you cannot and do not want to cope with any dynamism in
your system, don't introduce any other than what is controlled by yourself.
-> richard
>
> -John
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Managing Dynamism
Posted by jo...@exceter.com.
I'm interested in using OSGI as an update mechanism in a swing based
app. However, I'm concerned that managing the extremely dynamic nature
of OSGI is too difficult.
How can guarantee that the client's OSGI container will remain in a
known state which is identical to the state of the OSGI container that
I'm testing against? How can I guarantee that updates will be
installed, resolved, and wired in exactly the same sequence in the
client OSGI container and as they are in the OSGI container that I'm
testing against? If I cannot guarantee these things then I do not
understand how I can guarantee that my updates will succeed.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Moving fragment to Resolved state in fileinstall watched
directory?
Posted by lili_ili <sv...@gmail.com>.
Hi Justin,
Host bundle is a part of framework, fragment is a part of application
content.
In a standard flow fragment is always installed after host bundle.
thanks
justinedelson wrote:
>
> Is code running inside the framework? If so, why not just install the
> bundle directly (and the refresh the host bundle) rather than mucking with
> FileInstall.
>
> Justin
>
> On Jul 13, 2011, at 12:03 PM, lili_ili <sv...@gmail.com> wrote:
>
>>
>> Thank you, Richard. Can you recommend a java side solution?
>> I have an "installer" code that copies the fragment to the watched
>> directory. From there, I think to add a listener and after a fragment is
>> started redeploy its host. Is there a simpler solution?
>>
>> thanks again
>>
>>
>> Richard S. Hall wrote:
>>>
>>> If the host gets resolved first, then the fragment won't be able to
>>> attach to it since Felix doesn't support dynamic fragment attachment
>>> (and Equinox only supports it in a limited way). The most portable
>>> approach is to make sure the fragment is installed into the framework
>>> before the host is resolved.
>>>
>>> -> richard
>>>
>>> On 7/13/11 10:01, lili_ili wrote:
>>>> Hi
>>>>
>>>> I have a directory being watched by fileinstall. Fragment is copied to
>>>> this
>>>> directory after its host, and it automatically moves to "Installed"
>>>> state.
>>>> To make it "Resolved", I need to either run "resolve X" command, or
>>>> restart
>>>> the server.
>>>> Is there a way to solve it and resolve fragments located in "watched"
>>>> directories?
>>>>
>>>> thank you.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Moving-fragment-to-Resolved-state-in-fileinstall-watched-directory--tp32052770p32054785.html
>> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/Moving-fragment-to-Resolved-state-in-fileinstall-watched-directory--tp32052770p32089187.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Moving fragment to Resolved state in fileinstall watched directory?
Posted by Justin Edelson <ju...@justinedelson.com>.
Is code running inside the framework? If so, why not just install the bundle directly (and the refresh the host bundle) rather than mucking with FileInstall.
Justin
On Jul 13, 2011, at 12:03 PM, lili_ili <sv...@gmail.com> wrote:
>
> Thank you, Richard. Can you recommend a java side solution?
> I have an "installer" code that copies the fragment to the watched
> directory. From there, I think to add a listener and after a fragment is
> started redeploy its host. Is there a simpler solution?
>
> thanks again
>
>
> Richard S. Hall wrote:
>>
>> If the host gets resolved first, then the fragment won't be able to
>> attach to it since Felix doesn't support dynamic fragment attachment
>> (and Equinox only supports it in a limited way). The most portable
>> approach is to make sure the fragment is installed into the framework
>> before the host is resolved.
>>
>> -> richard
>>
>> On 7/13/11 10:01, lili_ili wrote:
>>> Hi
>>>
>>> I have a directory being watched by fileinstall. Fragment is copied to
>>> this
>>> directory after its host, and it automatically moves to "Installed"
>>> state.
>>> To make it "Resolved", I need to either run "resolve X" command, or
>>> restart
>>> the server.
>>> Is there a way to solve it and resolve fragments located in "watched"
>>> directories?
>>>
>>> thank you.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Moving-fragment-to-Resolved-state-in-fileinstall-watched-directory--tp32052770p32054785.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Moving fragment to Resolved state in fileinstall watched directory?
Posted by Carsten Ziegeler <cz...@apache.org>.
We have implemented such a feature in the Apache Sling OSGi Installer
which also supports file based installation like FileInstall :)
Carsten
2011/7/13 Richard Hall <he...@ungoverned.org>:
> On Wed, Jul 13, 2011 at 4:11 PM, Achim Nierbeck <bc...@googlemail.com>wrote:
>
>> I might be naive,
>
>
> Yes, you are. ;-)
>
>
>> but I think this would be a great feature for felix.
>> Often this is a real downside for using fragments that they don't get
>> attached because the host bundle
>> is already started, so you start tuning with startlevels which for me is
>> just a bad workaround.
>> Would this be a possible enhancement for felix?
>>
>
> No, this is a management agent issue, not a framework issue. This can all
> easily be handled on top in a bundle (or management agent), so there is no
> reason to bake this into the framework. However, you could consider opening
> an issue against File Install and suggest that it implement such a
> feature...that would make more sense to me.
>
> -> richard
>
>
>>
>> regards, Achim
>>
>> Am 13.07.2011 18:30, schrieb Richard Hall:
>> > On Wed, Jul 13, 2011 at 12:03 PM, lili_ili <sv...@gmail.com> wrote:
>> >
>> >> Thank you, Richard. Can you recommend a java side solution?
>> >> I have an "installer" code that copies the fragment to the watched
>> >> directory. From there, I think to add a listener and after a fragment is
>> >> started redeploy its host. Is there a simpler solution?
>> >>
>> > I'm pretty sure this was some discussion on this exact topic not too long
>> > ago...
>> >
>> > At any rate, you could write a bundle that listens for bundles to be
>> > installed. It could (after perhaps a short delay) determine if that
>> bundle
>> > was a fragment and if its matching host was already resolved. If so, it
>> > could then refresh and/or re-resolve the host, which would most likely
>> > result in the framework attaching the fragment. If the host is active,
>> then
>> > refreshing it should be sufficient since it will automatically get
>> > re-started and re-resolved.
>> >
>> > -> richard
>> >
>> >
>> >> thanks again
>> >>
>> >>
>> >> Richard S. Hall wrote:
>> >>> If the host gets resolved first, then the fragment won't be able to
>> >>> attach to it since Felix doesn't support dynamic fragment attachment
>> >>> (and Equinox only supports it in a limited way). The most portable
>> >>> approach is to make sure the fragment is installed into the framework
>> >>> before the host is resolved.
>> >>>
>> >>> -> richard
>> >>>
>> >>> On 7/13/11 10:01, lili_ili wrote:
>> >>>> Hi
>> >>>>
>> >>>> I have a directory being watched by fileinstall. Fragment is copied to
>> >>>> this
>> >>>> directory after its host, and it automatically moves to "Installed"
>> >>>> state.
>> >>>> To make it "Resolved", I need to either run "resolve X" command, or
>> >>>> restart
>> >>>> the server.
>> >>>> Is there a way to solve it and resolve fragments located in "watched"
>> >>>> directories?
>> >>>>
>> >>>> thank you.
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >>> For additional commands, e-mail: users-help@felix.apache.org
>> >>>
>> >>>
>> >>>
>> >> --
>> >> View this message in context:
>> >>
>> http://old.nabble.com/Moving-fragment-to-Resolved-state-in-fileinstall-watched-directory--tp32052770p32054785.html
>> >> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>
>> >>
>>
>>
>> --
>> -----
>>
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
>> Project Lead
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
--
Carsten Ziegeler
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Moving fragment to Resolved state in fileinstall watched directory?
Posted by Richard Hall <he...@ungoverned.org>.
On Wed, Jul 13, 2011 at 4:11 PM, Achim Nierbeck <bc...@googlemail.com>wrote:
> I might be naive,
Yes, you are. ;-)
> but I think this would be a great feature for felix.
> Often this is a real downside for using fragments that they don't get
> attached because the host bundle
> is already started, so you start tuning with startlevels which for me is
> just a bad workaround.
> Would this be a possible enhancement for felix?
>
No, this is a management agent issue, not a framework issue. This can all
easily be handled on top in a bundle (or management agent), so there is no
reason to bake this into the framework. However, you could consider opening
an issue against File Install and suggest that it implement such a
feature...that would make more sense to me.
-> richard
>
> regards, Achim
>
> Am 13.07.2011 18:30, schrieb Richard Hall:
> > On Wed, Jul 13, 2011 at 12:03 PM, lili_ili <sv...@gmail.com> wrote:
> >
> >> Thank you, Richard. Can you recommend a java side solution?
> >> I have an "installer" code that copies the fragment to the watched
> >> directory. From there, I think to add a listener and after a fragment is
> >> started redeploy its host. Is there a simpler solution?
> >>
> > I'm pretty sure this was some discussion on this exact topic not too long
> > ago...
> >
> > At any rate, you could write a bundle that listens for bundles to be
> > installed. It could (after perhaps a short delay) determine if that
> bundle
> > was a fragment and if its matching host was already resolved. If so, it
> > could then refresh and/or re-resolve the host, which would most likely
> > result in the framework attaching the fragment. If the host is active,
> then
> > refreshing it should be sufficient since it will automatically get
> > re-started and re-resolved.
> >
> > -> richard
> >
> >
> >> thanks again
> >>
> >>
> >> Richard S. Hall wrote:
> >>> If the host gets resolved first, then the fragment won't be able to
> >>> attach to it since Felix doesn't support dynamic fragment attachment
> >>> (and Equinox only supports it in a limited way). The most portable
> >>> approach is to make sure the fragment is installed into the framework
> >>> before the host is resolved.
> >>>
> >>> -> richard
> >>>
> >>> On 7/13/11 10:01, lili_ili wrote:
> >>>> Hi
> >>>>
> >>>> I have a directory being watched by fileinstall. Fragment is copied to
> >>>> this
> >>>> directory after its host, and it automatically moves to "Installed"
> >>>> state.
> >>>> To make it "Resolved", I need to either run "resolve X" command, or
> >>>> restart
> >>>> the server.
> >>>> Is there a way to solve it and resolve fragments located in "watched"
> >>>> directories?
> >>>>
> >>>> thank you.
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>> For additional commands, e-mail: users-help@felix.apache.org
> >>>
> >>>
> >>>
> >> --
> >> View this message in context:
> >>
> http://old.nabble.com/Moving-fragment-to-Resolved-state-in-fileinstall-watched-directory--tp32052770p32054785.html
> >> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
>
>
> --
> -----
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Moving fragment to Resolved state in fileinstall watched directory?
Posted by Achim Nierbeck <bc...@googlemail.com>.
I might be naive, but I think this would be a great feature for felix.
Often this is a real downside for using fragments that they don't get
attached because the host bundle
is already started, so you start tuning with startlevels which for me is
just a bad workaround.
Would this be a possible enhancement for felix?
regards, Achim
Am 13.07.2011 18:30, schrieb Richard Hall:
> On Wed, Jul 13, 2011 at 12:03 PM, lili_ili <sv...@gmail.com> wrote:
>
>> Thank you, Richard. Can you recommend a java side solution?
>> I have an "installer" code that copies the fragment to the watched
>> directory. From there, I think to add a listener and after a fragment is
>> started redeploy its host. Is there a simpler solution?
>>
> I'm pretty sure this was some discussion on this exact topic not too long
> ago...
>
> At any rate, you could write a bundle that listens for bundles to be
> installed. It could (after perhaps a short delay) determine if that bundle
> was a fragment and if its matching host was already resolved. If so, it
> could then refresh and/or re-resolve the host, which would most likely
> result in the framework attaching the fragment. If the host is active, then
> refreshing it should be sufficient since it will automatically get
> re-started and re-resolved.
>
> -> richard
>
>
>> thanks again
>>
>>
>> Richard S. Hall wrote:
>>> If the host gets resolved first, then the fragment won't be able to
>>> attach to it since Felix doesn't support dynamic fragment attachment
>>> (and Equinox only supports it in a limited way). The most portable
>>> approach is to make sure the fragment is installed into the framework
>>> before the host is resolved.
>>>
>>> -> richard
>>>
>>> On 7/13/11 10:01, lili_ili wrote:
>>>> Hi
>>>>
>>>> I have a directory being watched by fileinstall. Fragment is copied to
>>>> this
>>>> directory after its host, and it automatically moves to "Installed"
>>>> state.
>>>> To make it "Resolved", I need to either run "resolve X" command, or
>>>> restart
>>>> the server.
>>>> Is there a way to solve it and resolve fragments located in "watched"
>>>> directories?
>>>>
>>>> thank you.
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>> --
>> View this message in context:
>> http://old.nabble.com/Moving-fragment-to-Resolved-state-in-fileinstall-watched-directory--tp32052770p32054785.html
>> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
--
-----
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Moving fragment to Resolved state in fileinstall watched directory?
Posted by Richard Hall <he...@ungoverned.org>.
On Wed, Jul 13, 2011 at 12:03 PM, lili_ili <sv...@gmail.com> wrote:
>
> Thank you, Richard. Can you recommend a java side solution?
> I have an "installer" code that copies the fragment to the watched
> directory. From there, I think to add a listener and after a fragment is
> started redeploy its host. Is there a simpler solution?
>
I'm pretty sure this was some discussion on this exact topic not too long
ago...
At any rate, you could write a bundle that listens for bundles to be
installed. It could (after perhaps a short delay) determine if that bundle
was a fragment and if its matching host was already resolved. If so, it
could then refresh and/or re-resolve the host, which would most likely
result in the framework attaching the fragment. If the host is active, then
refreshing it should be sufficient since it will automatically get
re-started and re-resolved.
-> richard
> thanks again
>
>
> Richard S. Hall wrote:
> >
> > If the host gets resolved first, then the fragment won't be able to
> > attach to it since Felix doesn't support dynamic fragment attachment
> > (and Equinox only supports it in a limited way). The most portable
> > approach is to make sure the fragment is installed into the framework
> > before the host is resolved.
> >
> > -> richard
> >
> > On 7/13/11 10:01, lili_ili wrote:
> >> Hi
> >>
> >> I have a directory being watched by fileinstall. Fragment is copied to
> >> this
> >> directory after its host, and it automatically moves to "Installed"
> >> state.
> >> To make it "Resolved", I need to either run "resolve X" command, or
> >> restart
> >> the server.
> >> Is there a way to solve it and resolve fragments located in "watched"
> >> directories?
> >>
> >> thank you.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/Moving-fragment-to-Resolved-state-in-fileinstall-watched-directory--tp32052770p32054785.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Moving fragment to Resolved state in fileinstall watched
directory?
Posted by lili_ili <sv...@gmail.com>.
Thank you, Richard. Can you recommend a java side solution?
I have an "installer" code that copies the fragment to the watched
directory. From there, I think to add a listener and after a fragment is
started redeploy its host. Is there a simpler solution?
thanks again
Richard S. Hall wrote:
>
> If the host gets resolved first, then the fragment won't be able to
> attach to it since Felix doesn't support dynamic fragment attachment
> (and Equinox only supports it in a limited way). The most portable
> approach is to make sure the fragment is installed into the framework
> before the host is resolved.
>
> -> richard
>
> On 7/13/11 10:01, lili_ili wrote:
>> Hi
>>
>> I have a directory being watched by fileinstall. Fragment is copied to
>> this
>> directory after its host, and it automatically moves to "Installed"
>> state.
>> To make it "Resolved", I need to either run "resolve X" command, or
>> restart
>> the server.
>> Is there a way to solve it and resolve fragments located in "watched"
>> directories?
>>
>> thank you.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/Moving-fragment-to-Resolved-state-in-fileinstall-watched-directory--tp32052770p32054785.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Moving fragment to Resolved state in fileinstall watched directory?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
If the host gets resolved first, then the fragment won't be able to
attach to it since Felix doesn't support dynamic fragment attachment
(and Equinox only supports it in a limited way). The most portable
approach is to make sure the fragment is installed into the framework
before the host is resolved.
-> richard
On 7/13/11 10:01, lili_ili wrote:
> Hi
>
> I have a directory being watched by fileinstall. Fragment is copied to this
> directory after its host, and it automatically moves to "Installed" state.
> To make it "Resolved", I need to either run "resolve X" command, or restart
> the server.
> Is there a way to solve it and resolve fragments located in "watched"
> directories?
>
> thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org