I think part of the problem is that file install is not waiting for the refresh operation to complete before attempting to start all the bundles. See https://issues.apache.org/jira/browse/FELIX-3414
What I think ends up happening is that file install calls start on the
bundles it has just installed after it has called an async refresh packages
operation. This grabs a state change lock for the bundle. Now this lock
prevents the refresh packages background thread to obtain the state change
lock for the bundle that is being activated. You may want to give the
latest file install code a try to see if it fixes your issue.
Tom
From: "hbdrawn" <[email protected]>
To: "Equinox development mailing list" <[email protected]>,
Date: 06/15/2012 07:13 PM
Subject: [equinox-dev] 回复： 回复： equinox bundle akin to felix fileinstall
I think the operation of refreshing for uninstalledBundles and
updatedBundles is required, but not for installBundles。And maybe there are
some faults just like what Raymond said.
------------------
学会滑翔，宁静致远||梦依旧
------------------ 原始邮件 ------------------
发件人: "Raymond Auge"<[email protected]>;
发送时间: 2012年6月16日(星期六) 凌晨5:49
收件人: "Equinox development mailing list"<[email protected]>;
主题: Re: [equinox-dev]回复： equinox bundle akin to felix fileinstall
On Fri, Jun 15, 2012 at 10:23 AM, hbdrawn <[email protected]> wrote:
i encoutered the same problem before.After checked out the code,i found
the spilth code in the line of 502(maybe the original code had been
modified somewhere,so the line is not correct maybe,but the code below
is right,please check it) in the DirectoryWatcher.java( function
process):
toRefresh.addAll( uninstalledBundles );
toRefresh.addAll(updatedBundles);
//toRefresh.addAll( installedBundles );
This actually does seem to be the issue. Again I'm not sure who is at fault
because internally equinox is performing a refresh on bundles using a
separate thread which would clearly seem to violate the code in
AbstractBundle.beginStateChange which will quite clearly throw an error it
a separate thread has the bundle in a dirty state.
Perhaps there is no need for felix file install to actually force a package
refresh? Wouldn't that be automatically done by the framework itself on an
install/update/deletion?
Perhaps it's because it's trying to perform the process as a batch?
Here is the exact code in question:
// Handle deleted artifacts
// We do the operations in the following order:
// uninstall, update, install, refresh & start.
Collection uninstalledBundles = uninstall(deleted);
Collection updatedBundles = update(modified);
Collection installedBundles = install(created);
Set toRefresh = new HashSet();
toRefresh.addAll( uninstalledBundles );
toRefresh.addAll(updatedBundles);
toRefresh.addAll( installedBundles );
findBundlesWithFragmentsToRefresh( toRefresh );
findBundlesWithOptionalPackagesToRefresh( toRefresh );
if (toRefresh.size() > 0)
{
// Refresh if any bundle got uninstalled or updated.
refresh((Bundle[]) toRefresh.toArray(new Bundle[toRefresh.size
()]));
}
The error results from the second last line above, but if we comment the
line as bdrawn mentions above, then it eliminates the error, but does it
leave the system in a state it shouldn't be in?
--
Raymond Augé | Senior Software Architect | Liferay, Inc.
---
8-9 October 2012 | Liferay North America Symposium |
liferay.com/northamerica2012
16-17 October 2012 | Liferay Europe Symposium | liferay.com/europe2012
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
