You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Rob Abbe <ro...@oracle.com> on 2011/02/04 20:07:43 UTC
Applets, Felix and native code
I've been developing an application that runs in a felix container that
is hosted by an applet. The applet does little more that start an
instance of felix and install some bundles.
Several of the bundles have a native code requirement, Bundle-Native has
been implemented in this case. Everything resolves and the applet works
perfectly until I try and load it in another tab or try and load the
applet in the same tab after having browsed to a different website then
hit the back button. In these cases, I am greeted with the
UnsatisfiedLinkError Library already loaded by another class loader. I
understand the reason for this (each applet creates a new framework
instance and tries to start bundles that have been loaded by
classloaders in a previous instance), but I am not able to find an
acceptable work around.
I thought that creating an extension bundle would be a good work
around. I created the bundle extension and jar up the native code in
its own jar file and specify the jar file on the bundle class path. The
manifest for the extension bundle is as follows:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-ClassPath: .,twainwrapper.jar
Bundle-Name: Oracle Java TWAIN
Bundle-SymbolicName: oracle.jotwain
Bundle-Description: Oracle TWAIN Library for Java
Bundle-Vendor: Oracle
Bundle-Version: 1.0.0
Export-Package: oracle.jotwain
Fragment-Host: system.bundle;extension:=framework
Now when I load my applet I get a security exception when it attempts to
load the native code. I see the following exception:
java.security.AccessControlException: access denied
(java.lang.RuntimePermission loadLibrary.TWAINWrapper)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkLink(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at oracle.jotwain.TWAINWrapper$1.run(TWAINWrapper.java:141)
at java.security.AccessController.doPrivileged(Native Method)
at oracle.jotwain.TWAINWrapper.<clinit>(TWAINWrapper.java:138)
at oracle.jotwain.Controller.loadLibrary(Controller.java:56)
at oracle.jotwain.SourceManager.instance(SourceManager.java:35)
at oracle.ice.twain.TWAINDriver.getCaptureSources(TWAINDriver.java:253)
at
oracle.oddc.client.BatchEditForm.initScanBatchMenuButton(BatchEditForm.java:1090)
at oracle.oddc.client.BatchEditForm.<init>(BatchEditForm.java:389)
at oracle.oddc.client.FormManagerPanel$1.run(FormManagerPanel.java:292)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
This exception occurs when System.loadLibrary is invoked to load the dll
file. When implemented as a standard bundle the code loads fine except
in the circumstances I outlined above, so I know there is no problem
with the dll file.
The environment needs to be completely dynamic. Installing the
nativecode as part of the applet download is not an option as it defeats
the purpose of this design.
Any suggestions would be appreciated.
Thanks,
Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Applets, Felix and native code
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I'm not sure I understand. Native libraries must be packaged in the
bundle doing the System.loadLibrary() call, since the class loader
associated with the bundle is used to do the native library lookup.
If a new framework instance is being created each time, it sounds like
they must not have been garbage collected yet, otherwise there still
wouldn't be class loaders with a reference to the native lib. You could
use a unique cache directory each time you create an instance, which
would solve the exception, but not necessarily the garbage collection issue.
It would be better if you could avoid creating a new framework each time
and somehow store it in your session. Of course, I'm no web programmer,
so I have no idea what I'm talking about.
-> richard
On 2/4/11 14:07, Rob Abbe wrote:
> I've been developing an application that runs in a felix container
> that is hosted by an applet. The applet does little more that start
> an instance of felix and install some bundles.
>
> Several of the bundles have a native code requirement, Bundle-Native
> has been implemented in this case. Everything resolves and the applet
> works perfectly until I try and load it in another tab or try and load
> the applet in the same tab after having browsed to a different website
> then hit the back button. In these cases, I am greeted with the
> UnsatisfiedLinkError Library already loaded by another class loader.
> I understand the reason for this (each applet creates a new framework
> instance and tries to start bundles that have been loaded by
> classloaders in a previous instance), but I am not able to find an
> acceptable work around.
>
> I thought that creating an extension bundle would be a good work
> around. I created the bundle extension and jar up the native code in
> its own jar file and specify the jar file on the bundle class path.
> The manifest for the extension bundle is as follows:
>
> Manifest-Version: 1.0
> Bundle-ManifestVersion: 2
> Bundle-ClassPath: .,twainwrapper.jar
> Bundle-Name: Oracle Java TWAIN
> Bundle-SymbolicName: oracle.jotwain
> Bundle-Description: Oracle TWAIN Library for Java
> Bundle-Vendor: Oracle
> Bundle-Version: 1.0.0
> Export-Package: oracle.jotwain
> Fragment-Host: system.bundle;extension:=framework
>
> Now when I load my applet I get a security exception when it attempts
> to load the native code. I see the following exception:
>
> java.security.AccessControlException: access denied
> (java.lang.RuntimePermission loadLibrary.TWAINWrapper)
> at java.security.AccessControlContext.checkPermission(Unknown Source)
> at java.security.AccessController.checkPermission(Unknown Source)
> at java.lang.SecurityManager.checkPermission(Unknown Source)
> at java.lang.SecurityManager.checkLink(Unknown Source)
> at java.lang.Runtime.loadLibrary0(Unknown Source)
> at java.lang.System.loadLibrary(Unknown Source)
> at oracle.jotwain.TWAINWrapper$1.run(TWAINWrapper.java:141)
> at java.security.AccessController.doPrivileged(Native Method)
> at oracle.jotwain.TWAINWrapper.<clinit>(TWAINWrapper.java:138)
> at oracle.jotwain.Controller.loadLibrary(Controller.java:56)
> at oracle.jotwain.SourceManager.instance(SourceManager.java:35)
> at
> oracle.ice.twain.TWAINDriver.getCaptureSources(TWAINDriver.java:253)
> at
> oracle.oddc.client.BatchEditForm.initScanBatchMenuButton(BatchEditForm.java:1090)
> at oracle.oddc.client.BatchEditForm.<init>(BatchEditForm.java:389)
> at
> oracle.oddc.client.FormManagerPanel$1.run(FormManagerPanel.java:292)
> at java.awt.event.InvocationEvent.dispatch(Unknown Source)
> at java.awt.EventQueue.dispatchEvent(Unknown Source)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown
> Source)
> at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown
> Source)
> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
> at java.awt.EventDispatchThread.run(Unknown Source)
>
> This exception occurs when System.loadLibrary is invoked to load the
> dll file. When implemented as a standard bundle the code loads fine
> except in the circumstances I outlined above, so I know there is no
> problem with the dll file.
>
> The environment needs to be completely dynamic. Installing the
> nativecode as part of the applet download is not an option as it
> defeats the purpose of this design.
>
> Any suggestions would be appreciated.
>
> Thanks,
>
> Rob
>
> ---------------------------------------------------------------------
> 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