Are you trying to use fileinstall to deploy configadmin ?
That's not really supported, but it should not be very difficult to support.
Please raise a JIRA.

I think allowing all configuration bits to be available from the bundle
context would be a good work around.


2014-04-29 20:13 GMT+02:00 Raymond Auge <[email protected]>:

> It would seem that this could be solved it it were possible to pass the
> property:
>
> felix.fileinstall.optionalImportRefreshScope=managed
>
> but this property cannot be passed except via config admin, so you can't
> bootstrap the system as it is.
>
> - Ray
>
>
> On Tue, Apr 29, 2014 at 1:28 PM, Raymond Auge <[email protected]
> >wrote:
>
> > Hey All (cross posted as I'm not sure where the answer will come from),
> >
> > versions:
> > - fileinstall 3.4.0
> > - equinox 3.8.0.v20120529-1548
> >
> > I'm seeing a deadlock where on first start the fileinstall bundle is
> > getting stuck with itself
> >
> > as per the following two stack traces:
> >
> > "Refresh Packages" daemon prio=10 tid=0x00007fc29c0f6800 nid=0x94c
> waiting on condition [0x00007fc2b9c15000]
> >    java.lang.Thread.State: WAITING (parking)
> >       at sun.misc.Unsafe.park(Native Method)
> >       - parking to wait for  <0x00000000c095f950> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> >       at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> >       at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> >       at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> >       at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> >       at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)
> >       at
> org.apache.felix.fileinstall.internal.FileInstall.stop(FileInstall.java:171)
> >       at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:771)
> >       at java.security.AccessController.doPrivileged(Native Method)
> >       at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:764)
> >       at
> org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:510)
> >       at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:566)
> >       at
> org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1207)
> >       at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBundle(PackageAdminImpl.java:326)
> >       at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:467)
> >       at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251)
> >       - locked <0x00000000c0cbc1f8> (a
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl)
> >       at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174)
> >       at java.lang.Thread.run(Thread.java:744)
> >    Locked ownable synchronizers:
> >       - None
> >
> >
> > "fileinstall-/home/rotty/AS/liferay-portal/osgi/portal" daemon prio=10
> tid=0x00007fc2ac01a000 nid=0x920 waiting on condition [0x00007fc2ba721000]
> >    java.lang.Thread.State: WAITING (parking)
> >       at sun.misc.Unsafe.park(Native Method)
> >       - parking to wait for  <0x00000000c51bd048> (a
> java.util.concurrent.CountDownLatch$Sync)
> >       at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> >       at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> >       at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> >       at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> >       at
> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> >       at
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:319)
> >       at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:674)
> >       at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:495)
> >       at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:358)
> >       at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:310)
> >    Locked ownable synchronizers:
> >       - None
> >
> > You can see that the refresh event will never return (to tear down the
> > latch) as long as the FileInstall.stop operation can't get the lock in to
> > directory which it's currently holding during the refresh operation!
> > What seems strange is that fileinstall is adding itself to the list of
> > bundles to refresh during the
> > findBundlesWithOptionalPackagesToRefresh(toRefresh); call. Is that
> expected?
> >
> >
> > Sincerely,
> > --
> > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> >  (@rotty3000)
> > Senior Software Architect
> > *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
> >
> >
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>  (@rotty3000)
> Senior Software Architect
> *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
>

Reply via email to